Global variable "paths" overflows

[MinnieTheMoocher]

the current master codeline (up to commit f3a7dd4) to me appears to have a bug at the global variable "paths".

It gets initialized ONCE as empty array paths = [], but EACH call of the function "locate" appends more and more values to it.

The fix is easy.
Simply initialize it ONCE, BEFORE all the part loading stuff starts.

[le717]

You are confusing me a bit. In #40 (comment) you said

(b) speed: the paths[] array construction should be moved out of the locate function. it is expensive and only needs to be done once.

It has been moved out of the locate() function since f0037a7, so I'm quite sure where it needs to be now. It is already in the global namespace, so to initialize it any sooner it would have to be moved near the top of the script, around line 50 I'd imagine.

[MinnieTheMoocher]

It has been moved out of the locate() function since f0037a7

No, it hasn't. It gets initialized outside, but each call to locate appends more and more entries.
Look at the calls
paths.append(...)
which, even after that change all are inside the locate() function
and this way get executed each time that function gets called,
which is what this issue complains about.

[le717]

I think I get it now. You are talking about the multiple calls to locate() that almost continually runs paths.append(...) , right?

[MinnieTheMoocher]

No. The multiple calls to locate() are OK.
They happen each time the script tries to locate a required file.
The bug instead is that inside EACH of those calls, the variable paths gets its .append() calls.
They put more and more stuff into that variable each time the function locate() is running.
This is wrong.
Instead, the paths variable should only get filled ONE time, before starting all the loading action.
The locate() function should not tinker with that variable, just READ it.

[le717]

OK, I see what you mean now. Checking the length of the array produced a very large number. So the fix would be to initialize the paths locate() appends with the paths array, as you've been saying.

However, there still has to be some editing somewhere. Since the array starts out with the HighRes and LowRes paths present, the inverse will have to be removed from the array if either of those flags are True. Appending them might work, but then we end up with the importer searching the folders in the wrong order, something we fixed in #52.

[MinnieTheMoocher]

come on, it is not that complicated. simply MOVE the paths.append() calls to the beginning of the script,
right after where the values for HighRes and LowRes are known.

The paths array then can stay as it is the whole lifetime of the script.

There is no need to modify it again.

Its search order will be correct and will be used for every file loaded.

The bug we talk about here is just that the PLACE of the paths.append() calls is wrong.

They ALL should simply be done BEFORE the first call to locate() and then never again.

The whole discussion here already took more time to EXPLAIN the problem than to FIX it... :´(

[le717]

Assigning to v1.1.5 milestone.

[le717]

ad87d66 should finally fix this. 😅

Apologies for not understanding the issue completely. I didn't mean to annoy you. Sometimes I have trouble understand what people are trying to explain (it probably stems from my inability to sometimes explain what I am taking about). 😟

[le717]

If everything looks good, I'll merge this and prepare the v1.1.5 release.

[le717]

This should be fixed by #56. Closing. 👍