Inline function triggered by a callback = execution timeout

[Lindon]

@Christoph-Hart said in Inline function triggered by a callback = execution timeout:

Yes the problem is that if you hit the timeout execution the inline function can't clean up after itself and thus it will think it is called recursively every time you call it normally.

I also experienced the timeout issue, but if one of you can make a minimal example that reliable causes the timeout to occur, it would speed up the fixing process.

I've tried - but it wont do it - however I have made a version that calls a timer and executes the .findFiles from there - If I set the time to 2000 it seems to work reliably(..on my machine) -- not sure that helps resolve the problem any....

[Lindon]

@Lindon damnit - no it doenst...

[ps]

@Christoph-Hart ok i was trying to recreate it in a smaller snippet and obviously no problems - no matter how hard I pushed it...

At some point I had basically everything recreated and there was only one thing missing - a panel with a paint routine... And voila - Execution timed-out.

And I'm not talking about a paint routine related to the functions, external repaint or anything. Just adding:

const var Panel1 = Content.getComponent("Panel1");

Panel1.setPaintRoutine(function(g)
{
	g.drawAlignedText("Test", [0,0,this.getWidth(),this.getHeight()], "centred");	
});

to the script already caused it.

[d.healey]

@ps That paint routine alone isn't causing the issue, keep trying to narrow it down.

[Lindon]

@d-healey I think he's saying that the function works fine, then adding a completely unrelated paint routine breaks the function....but adding an unrelated paint routine to my simple example doesn't break it....

[d.healey]

@Lindon But does adding anything else totally unrelated also break it... the paint routine might be a red herring.

Since the paint routine on its own doesn't cause an issue what else can be removed from his project that will make the issue go away.

[ps]

OK. I'm not gonna say that this makes any logical sense but here we go:
This is the most simple version I could make to get the timeout - If I comment out the Paint Routine no timeout - so there has to be a relation even if it's very abstract.

EDIT: The execution timeout will happen at the for loop if the paint routine is in the code just fyi

/// FUNCTION CALLING A JSON + RESPONSE TRIGGERS ANOTHER INLINE FUNCTION

inline function loadjsn()
{
Server.setBaseURL("https://something.com");

Server.callWithGET("/something", "", function(status, response)
{   
 test();    
});  
	
}

loadjsn();

/// HERE WE NEED THE FIND FILES FUNCTION  (IT WAS JUST A COUPLE FILES ON AN SSD) + FOR LOOP THAT PUSHES INTO THE ARRAY IS NEEDED AS WELL

inline function test()
{
local files = FileSystem.findFiles(FileSystem.getFolder(FileSystem.Samples),"*.wav",1);

local array = [];

for (x in files)
array.push(x.toString(1));

Console.print(array.length);		
}


///COMPLETELY UNRELATED PAINT ROUTINE - NO TIMEOUT WHEN COMMENTED OUT

const var Panel1 = Content.getComponent("Panel1");

Panel1.setPaintRoutine(function(g)
{
g.drawAlignedText("Test", [0,0,this.getWidth(),this.getHeight()], "centred");	
});

[d.healey]

@ps What happens if instead of calling loadjsn(); you call test();? So you bypass the server call entirely.

Also what happens if you change the order of the paint routine and loadjsn()? since they are both triggering in on init.

Also I'd avoid calling your Array array - I don't think it will cause a problem but it's not usually a good idea to give a variable the name of a type.

[ps]

@d-healey as said if I skip any of the parts I don't get the timeout - it only happens if the function get's called by a callback and contains FindFiles and for loop.
The naming in my example here should not reflect my usual naming conventions ;)

[ps]

@d-healey the order unfortunately doesn't make a difference.

[d.healey]

@ps I need a snippet I can test on my system, can you share the real server endpoints? Do you need to use findFiles or can you put some dummy data in there?

[ps]

@d-healey you can use it exactly this way - the actual response doesn't matter, I had real endpoints before but it also happens exactly that way with a dummy endpoint the crucial factor seems to be that the callback is executing it - just change the FindFiles to something where it can actually find files on your system and it should happen. (Can only speak for MacOs right now)

EDIT: If it doesn't find files - no timeout

[d.healey]

@ps Ok I'll play around with it

[d.healey]

@ps I pasted your code, pointed findFiles to a folder containing 3 wav files, hit compile, no issues. Might be a MacOS only thing. I'll test on my Mac.

[Lindon]

@d-healey --no this problem with findFiles is happening on my Windows machine...

[d.healey]

@Lindon Do you have a minimal snippet that causes it?

[Christoph Hart]

@ps can you reproduce the timeout with a dummy loop that does nothing instead of findFiles (eg calculating 100000 sin values?

[ps]

@Christoph-Hart ok it seems the loop itself is pretty unrelated.
I can also get the timeout with find files in the function and a random loop generating Numbers. The moment I comment out find files.. no timeout.

The following executed by the response callback is enough to break the script - if find files function is in there I'll never see the beautiful numbers in the console.
BTW not it doesn't matter anymore if it actually finds files. Before that I was looping through the results - so no results no loop iteration.

I can EITHER remove the Paint Routine or the FindFiles line to execute the loop

inline function test()
{
local files = FileSystem.findFiles(FileSystem.getFolder(FileSystem.Samples),"*.anything",1);
	
for (i=0;i<100;i++)
{
Console.print(Math.random());	
}	
}

[d.healey]

It works fine here on my Mac. @ps What Mac are you using?

[Lindon]

@d-healey said in Inline function triggered by a callback = execution timeout:

It works fine here on my Mac. @ps What Mac are you using?

--its broken here on my PC too - so its not a mac issue.