ValueError: invalid literal for int() with base 10: '1)'

[koshMer]

ValueError: invalid literal for int() with base 10: '1)'

[tchlux]

Hmm, I know exactly what's happening. The code is trying to parse the contents of the angle( ... ) and it is only prepared to see an integer or a reference to another variable there. A quick fix is to use angle(SIZE(n, 1), SIZE(n,2)) I believe, but I can look more into it this evening!

If you're interested in knowing how it works, the lines of code that parse out the assumed shapes of objects are here:
https://github.com/tchlux/fmodpy/blob/1.3.3/fmodpy/parsing/argument.py#L561-L591

[koshMer]

Thanks for the fast reply :)
I went through the code a few times and i think i now have at least some understanding of what it does.
You seem to use "," as the identifier to differentiate between SIZE(array) and SIZE(array,axis). In the case above, there is "," in size() but no axis.
A quick fix (maybe?) could be to change

 if "," not in argument:

(L581) to

  if "," not in argument or ")," not in argument:

But that's not so general I think.

[tchlux]

Good find! Yeah, but this code actually needs to translate the contents of SIZE(...) into viable Python code. That means wherever parentheses are used as indices they need to replaced by squared brackets. And any integer indices need to be shifted by -1. For efficiency's sake, if there are constant expressions then I should be actually computing their value and subtracting one from that (as in your case above).

So this is a little bit more involved of a fix to handle a reasonable number of cases. It might be a little while before I push a fix. For now, I would recommend using the SIZE(<array>, <axis>) formulation to make things work as is.

[tchlux]

Okay, implemented a fix! 😁 Version 1.3.4 is now up and you can see the new logic in the code here:
https://github.com/tchlux/fmodpy/blob/1.3.4/fmodpy/parsing/argument.py#L570-L611

I tested it on the exact code block you have above and it appears to produce a correct result. However, I'll mention I think this is slightly less efficient on the Python wrapper side than doing SIZE(n, 1) and SIZE(n, 2), since accessing indices in the shape is faster than slicing and measuring the size.

[koshMer]

Thanks! I'll have a look at it.
I switched to SIZE(n,1) etc. because I think that it also looks a bit cleaner and is faster to understand than SIZE(n(:,1)).