Weird lua table order bug (APFS related)? Bug in my code?

Hi,

in this tool, the order of the plugins is not like I wrote it into the table, only on macos 10.13.6 with APFS. It is correct on my 10.13.4 HFS+ machine. Maybe it is not related to APFS/HFS at all, but that’s the only difference I can imagine, also read about plenty of file sorting bugs in plugins related to APFS.

So this is how the menu looks like on HFS machine:

8338 Bildschirmfoto 2018-12-24 um 10.54.52.PNG

And here on APFS machine:

8339 Bildschirmfoto 2018-12-24 um 09.58.40.png

Also, if you do these tool settings:

8340 Bildschirmfoto 2018-12-24 um 10.54.32.PNG

there should appear two main entries, but it is not on APFS machine:

8341 Bildschirmfoto 2018-12-24 um 10.54.40.PNG

So are the popup menues somehow stored as files on the harddrive?? Is it sqllite related?

If I change the second loop from pairs() to ipairs(), the sorting will be correct on both machines. Still I don’t get this: Shouldn’t be the order exactly like I wrote it down?

The pairs iterator return values in a non-specific order. If you want to sort them alphabetically, you can make a custom iterator (or use table.sort directly on a “cloned” table).

Thanks, but I want to keep the order I wrote it, it is not alphabetically, but custom.

Then provide a custom table. Keep it indexed and use ipairs to get consistent results.

Does the tool work correctly on your machine or not?

What constitutes it working incorrectly? You say that the sorting is always correct with ipairs but not with pairs, which is what is to be expected in LUA.

I actually think now that it has something to do with the removing and rebuilding of the menus: If a setting was changed, the menu will be removed (saved in a temp table “addedMenus”). Somehow this removing does not work on the other machine. I have no idea why.

What constitutes it working incorrectly? You say that the sorting is always correct with ipairs but not with pairs, which is what is to be expected in LUA.

Are the dsp entries like I posted it above on your machine? So the (dep.) devices are on the bottom? Even after loading a song?

Look: There is a manually written custom table with a specific order. On the one system, it works, on the other, it is not. So the result is not the same on different machines, but it should. I don’t even know now, if it is really pairs() vs ipairs() related anymore, maybe it’s about a bug in removing context menu entries.

And if I write a custom table with a specific order into my code, shouldn’t even pairs() return it in the order like I wrote (I actually now think that pairs() also does on the other system).

If you do not test the tool, you do not exactly know what I mean.

No, pairs will in some likelihood produce inconsistent results. Change that to ipairs and I will try later.

Man, you are so lazy ^_^Can’t you change it yourself? I won’t change the tool on the tools page, since it does not seem to fix it (tool ran fine for years). If I change it to ipairs, the second bug will appear (no more two main menus “add legacy” and “add native”).

Ok actually it is xmas, merry xmas to you.

Here is a version with ipairs, runs fine on the hfs machine, and on the apfs machine, it does not show the second menu, for unknown reason. I also now initializing the tool in the idle observer, did not change anything.

I would be curious, if you can even replicate the problem at all?

8342 ffx.tools.NativeDSPContextMenu.xrnx

As a sidenote, I read about that there was randomness added latelyat some array functions in all oses, some security bullshit, maybe lua is dependent on some standard c-lib sorting or so? 10.13.6 has those more recent slowdown-patches included, spectre3a or something.

I get both menus if i only tick the top option (showtwo Menus ).

(If I tick both, I only get the ‘native’ menu. If that’s intended, it’s very bad UX. Generally, you shouldn’t remove/restrict something with a tick box that implies that something is ‘enabled’)