Inline function triggered by a callback = execution timeout
-
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"); });
-
@ps What happens if instead of calling
loadjsn();
you calltest();
? 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.
-
@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 ;) -
@d-healey the order unfortunately doesn't make a difference.
-
@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?
-
@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
-
@ps Ok I'll play around with it
-
@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.
-
@d-healey --no this problem with findFiles is happening on my Windows machine...
-
@Lindon Do you have a minimal snippet that causes it?
-
@ps can you reproduce the timeout with a dummy loop that does nothing instead of findFiles (eg calculating 100000 sin values?
-
@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()); } }
-
It works fine here on my Mac. @ps What Mac are you using?
-
@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.
-
@Lindon @ps Just to confirm we're all doing the same test, here is the snippet I'm using, constructed from ps's code.
HiseSnippet 1170.3ocsV01aaaCDlJIpnVacXEX+.H7mjWbcr255FVVwpisbh5rkDrjqWwvPAqDsMWjHMDoSqwP96ree6C66aGk7aYIHq0.S.1R2a7t64NdjA4hXpTJxQFUhVNmhL9Tyvkb0rNyHLNxsKx3yLGPjJZNtj0YKmSjRZBxv3vy0LLpbDp34O+wyHoDdLcKKD5UBVLsOKio1xM3E+DKMsGIgFwx1Q6m9B2XAuiHUr.hmCMahlShujLk5QzpcfIx3ANILkHOTQTTInyYhjkgyDuiWp+qXR1aSoZhVnPXgJYi5LiklDrNWkHjwQAay7CKy7uvb.Kgsg+VD3yKDf2ZwtXfwA2WH05iHjL1IjNpLjdrYXbNatZqDc77IltbnfLg.P8tgRotnC9qCM6H.M3pFYjKo8xAhMVX+rlMqig+pcpk0ImbBt2HuNQt9d3Ns62206bba7KCAxiwCcBC78BcvQCcO+bmgg31d9QW3LD65AZ5rwTKKFOkwo3IK3wJlfiSEjjeSxsqY86VUBo4WQyaHopyHR5ng8sqNSolK+9SNQJxnpYL9zFwhrpPHUYi5wjzzwL0rychrqtUwp0wUgeq8jsDv8Ex53bpbtfKo0rp.tDWAJFJ6ZmhwVUtt1oUrt1xZSPsJygLwAO1A643zEC4EtmqWW3u9NgaQErsaDdb6P7KGEFAXSG+QA8cVoEHusGNLraM.t54OD222O.Vp1Q3fQgW.Z35E4Wr1sGNr8qwtgEdC7Grhic52+1PWYfqwsTAfA3IrTpD+bbO3c3RXmXViILdhlTZuCyoTUOQZBMeWlgjr4fd0.P6KaP3KWCgsJg5Ih7J1rm27TL6GZ0T+53iKAvJPGjTjRaLOmwU1CHpYMxI7DQlcMssWqAT.D63O.fiHm9uFOxanS+1QPtEzFRa7P+QQ5tjmf8.HvcfCPiGegCzo4OXfimVSfkkEroWpvWQxwADNMsEjrq6egjpiHCJr.gc0Rw51DqxO08TAv1T0PwBEfh1aZKlVffSajjSdW6T1TNMIh9dXMh.3E.feoY8l0AzPpcwXVhZlcsMzWPYSmAEgeEfsXvy4zjpE8P0NcSYRv8DJp+pVb.Mv+aQSlbmxzoVtHMEJT2kX8Hw76yPa9hr2RyqC.V5B5FEgYF2bPzC9vFDEWhz6nnf6xYJ+4zUzEcUIkee6wVnUkJ3qQtcIJhdR1Jdfdyo4JlNbL5RuBNJnbtVEytT4kJw7BcWUegLPUH8Qqm5oqwHF35GZVVuQuGYXZXYfPK0e7GEmlbqolv7ZQxhTh5lCw0mVsR..n2Xxod5HWxTK28zrOhI6Mu2I6eng3iMCXp3Y2cLdvcDi.T++QLt57vGY5LYBMVsM.Oxr2OuuG98e39xMvSg4L4LcQ1aQVHbMfXJ3cNT5k558A51sR5lZZMBDR4IED+M7rRXKMswJgsVKDkQhyEuItbaj9D2GVvAhIdwELp.2zAnwsPEas.6La1nIJCN7+Mww5z+IvNf61luZOr4q2Cad5dXy2rG17r8vlucOr46tWaz26p8BkHqb6.vHvoXFiggCm.cVEcgn+Afiwlu+
-
Ok just to get a little bit more systematic:
- both macOS / windows
- only the
findFiles()
call is affected. Using a loop to simulate a heavy task doesn't trigger. BTW, you can useConsole.startBenchmark()
andConsole.stopBenchmark()
before and after the loop to find out how long it takes. Try increasing the loop count until the timeout happens and then let me know what's the value that is causing the timeout (it definitely triggers the timeout after a certain period of time). - it happens only if the findFiles() call is happening in a callback. Does it also happen with
Engine.showYesNoWindow()
? This is the most simple callback to reproduce.
-
As far as I could reproduce only findFiles() in combination with a loop in the same function leads to timeout when executed by a callback.
But this is getting stranger and stranger. In the meantime I cleaned the build directory - compiled a plugin and after that tried my little dummy code again. Suddenly no timeout (At least not every time... before that it was a sure thing). Once I push the loop harder (1000 instead of 100 values) it's back again. (unless I remove find files or the paint routine). Also in larger projects it seems to be related to the workload of the function somehow.
Where should I place the Console.stopBenchmark() because when I get the timeout it never reaches the stop point.
-
@ps How many files are in the folder you are scanning with
findFiles
? -
Where should I place the Console.stopBenchmark() because when I get the timeout it never reaches the stop point.
Remove the findFiles call, then put the
stopBenchmark()
call after the loop and play around with the loop length to find the spot where it times out. Then check what value it prints for the highest loop count you can get it to run through. -
@d-healey I tried different locations with different amounts.
I just searched through 3 big folders taking 300ms without a loop no problem - adding just a dummy loop printing 10 numbers - timeout
and again removing the paint routine - no problem for the full function at all