iii debugging tips

[vijaymarupudi]

I'm curious what debugging tips people have discovered while programming with iii.

I'm particularly confused at moments when even ps(...) doesn't run in the grid(x, y, z) callback.

Here's an example script which demonstrates this issue:

https://gist.github.com/vijaymarupudi/1816d9a9aeefe898864fb054a26f55cc (24680 bytes)

This script is written so that it can run unmodified in both seamstress (and norns, I think) and iii. This is my debugging tip: it allows me to test whether the issues are in my logic or the platform specific parts. It also reduces the time taken to develop a script as I don't have to go through diii to upload a script and test it.

When you run the script in seamstress, you see 16 buttons, each 8 buttons long. Pressing on each button illuminates the entire column.

A proof of concept script with only a single column runs fine in both environments.

However, when I run the 16 column script in iii, it stops working after the first, second, or third button press, and the grid becomes unresponsive to further script uploads. I've tried reducing the computational load by reducing the frame rate (currently 24fps, line 1012), but it doesn't seem to help.

Would appreciate any tips on how to diagnose errors in such circumstances!

[tehn]

it seems like there's an underlying issue with grid keys getting lost, so i'll debug this ahead of checking out your script as a test case. thanks for submitting it.

[vijaymarupudi]

Sure! I don't think it's the same issue here, but the process of fixing that might identify an underlying cause.

[vijaymarupudi]

So I updated to the latest firmware, and it seems like I get syntax errors everytime I try to upload this script to the grid. I know that there are no syntax errors due to successful execution through seamstress. I wonder if the data for larger scripts is not being uploaded properly to the grid?

[vijaymarupudi]

[string "WFOIENIOENRSTXCDWFPRST_require_amalgamation_t..."]:2: 'end' expected (to close 'function' at
 line 1) near <eof>-- lua error:
[string "local function round(num)"]:2: 'end' expected (to close 'function' at line 1) near <eof>-- l
ua error:
[string "   return math.floor(num + 0.5)"]:1: attempt to perform arithmetic on a nil value (global 'n
um')-- lua error:
[string "end"]:1: <eof> expected near 'end'-- lua error:
[string "local function clip(num, low, high)"]:2: 'end' expected (to close 'function' at line 1) near
 <eof>-- lua error:
[string "   if num > high then"]:2: 'end' expected (to close 'if' at line 1) near <eof>-- lua error:
[string "   elseif num < low then"]:1: <eof> expected near 'elseif'-- lua error:
[string "   else"]:1: <eof> expected near 'else'-- lua error:
[string "   end"]:1: <eof> expected near 'end'-- lua error:
[string "end"]:1: <eof> expected near 'end'-- lua error:
[string "return {"]:2: unexpected symbol near <eof>-- lua error:
-- lua error:

[tehn]

ah, i reduced the script buffer to 16k during testing to assess the heap size. i'll push it back up to 32k.

also, just an observation: your test script to me has a huge amount of abstraction--- lots of code to do simple things. i am not completely confident that this will run well (if at all how you want) on such a constrained CPU and memory footprint.

i might suggest considering some of the more lightweight approaches to script building similar to what we present in the norns studies.

[vijaymarupudi]

Ah I see, will test it out when it is pushed back up!

Yeah, there is a lot of abstraction in there haha. I put it on the grid to test it, as there are many interaction patterns in there that I wanted to see if they'd be possible or feasible to run :) I have scripts that do more, but I wanted to test with a relatively simple (I know... I know...) one.

---

As a side note for more context: This is the code I've been using for seamstress. It's part of a project to develop a comprehensive widget framework to quickly test out ideas for scripts when I have them instead of starting from scratch everytime. It also served as an excuse to learn the structure and problems associated with retained mode graphics programming.

I know it's a lot of code, but not much code actually runs in response to specific actions. It makes it easier for me to associate an action with quick taps, holding, quick tapping and then holding, rendering animations, blinking buttons, etc. Tabs, overlays, stacks, menus, are much more easy to program as well. More recently I've been doing this stuff in C++, for which the amount of code runs practically instantly, but lua on the computer has been fast enough for me as well. My suspicion is that the grid's lua intepreter can handle all this abstraction fine, but yeah, code size is probably the biggest barrier. My hope is to make this work, but if not, then will have to resort to simple techniques.

The grid has been an excellent outlet for my programming hobby, so some amount of over-engineering was probably a result of that :)

[tehn]

absolutely! any way you want to go about it is fine, i simply wanted to re-alert the system limitations.

[vijaymarupudi]

Updated to the latest firmware, but now the code uploads successfully and runs. However, I'm running into the same bizarre bug, where the grid key callback stops getting called :( All metros stop running as well. Given that I've seen error reporting in diii in cases where I do make a type error in Lua, and the fact that I verified that this program runs fine in seamstress, I currently lean towards this being an issue in iii. However, I don't know what the exact cause of this issue, and how to reproduce it using a more minimal script.