"Ink Compiler timed out while the file was importing."

[Lattyware]

I'm running in the Linux editor (2016.3.0f1), and while compilation works (the json is created), I then get this error:

Ink Compiler timed out for /path/to/file.ink while the file was importing.
. Please report as a bug with the following error log at this address: https://github.com/inkle/ink/issues
Error log:
System.Collections.Generic.List`1[System.String]
UnityEngine.Debug:LogError(Object)
Ink.UnityIntegration.InkCompiler:Update() (at Assets/Plugins/Ink/Editor/Compiler/InkCompiler.cs:82)
UnityEditor.EditorApplication:Internal_CallUpdateFunctions()

I've changed the path there, as the original is very long. The only change I've made is to modify the path for mono as on my Linux system it's in /usr/bin/mono.

That error seems to be just printing out the list rather than the content, so I changed the line to:

Debug.LogError("Ink Compiler timed out for "+compilingFile.inkAbsoluteFilePath+" while the file was importing.\n. Please report as a bug with the following error log at this address: https://github.com/inkle/ink/issues\nError log:\n ---"+string.Join(",", compilingFile.errorOutput.ToArray())+"---");

This shows the list is empty:

Ink Compiler timed out for /home/gareth/Work/assets/Assets/Data/OutgoingEmails/SellHeaven.ink while the file was importing.
. Please report as a bug with the following error log at this address: https://github.com/inkle/ink/issues
Error log:
 ------
UnityEngine.Debug:LogError(Object)
Ink.UnityIntegration.InkCompiler:Update() (at Assets/Plugins/Ink/Editor/Compiler/InkCompiler.cs:83)
UnityEditor.EditorApplication:Internal_CallUpdateFunctions()

If I manually run the compiler as the editor is doing, it compiles with no error output and a 0 return code - no errors in sight.

[rikkhill]

Same problem, same platform, same setup.

I've spent a little while debugging this. I hadn't touched either C# or Unity until a couple of weeks ago, so I don't know how to remedy either of these things, but here are my findings:

1. In the Linux version of Unity Editor, the editor progress bar prevents the delayCall callback from firing. Unfortunately, this callback is what clears the stack (and the progress bar), and if it never does this, the loop in Update() will continue to evaluate even if the whole stack has been processed, so it will eventually time out.

2. If I close the progress bar, either programmatically or by manually closing it, my .inks will be compiled in a timely fashion, but OnProcessError() fires with a weird message string. It's of length 1 (so it passes the null/zero-length guards) but if I try and evaluate the Byte value of that character, I get System.OverflowException: Value is greater than Byte.MaxValue. So maybe it's getting garbage from stderr?

My current hacky workaround is to programmatically close the progress bar at the end of Update() if there are no files currently compiling, and to change the guard conditions on the error processor to discard messages of length less than a single character.

[tomkail]

Hmm that's pretty awful.The I think instead of shutting it down in update we should simply not show the progress bar on linux, but the rest of the fix sounds great. Since I can't test it, I dont suppose either of you can test and submit a pull request?

…

On Tue, Jan 23, 2018 at 1:40 AM, Rikk Hill ***@***.***> wrote: Same problem, same platform, same setup. I've spent a little while debugging this. I hadn't touched either C# or Unity until a couple of weeks ago, so I don't know how to remedy either of these things, but here are my findings: 1. In the Linux version of Unity Editor, the editor progress bar prevents the delayCall callback from firing. Unfortunately, this callback is what clears the stack (and the progress bar), and if it never does this, the loop in Update() will continue to evaluate even if the whole stack has been processed, so it will eventually time out. 2. If I close the progress bar, either programmatically or by manually closing it, my .inks will be compiled in a timely fashion, but OnProcessError() fires with a weird message string. It's of length 1 (so it passes the null/zero-length guards) but if I try and evaluate the Byte value of that character, I get System.OverflowException: Value is greater than Byte.MaxValue. So maybe it's getting garbage from stderr? My current hacky workaround is to programmatically close the progress bar at the end of Update() if there are no files currently compiling, and to change the guard conditions on the error processor to discard messages of length less than a single character. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#45 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABMd0H7RovTjmBm2ejj4WvVUM3ZBRu1jks5tNThzgaJpZM4REVCZ> .

[rikkhill]

If you’d like out-of-the-box Linux compatibility, I’m happy to test and submit a PR with the following content:

• Inclusion of /usr/bin/mono in the locations where the compiler script checks for Mono. (This isn’t necessarily where Mono lives. The Linux Unity Editor allegedly ships with its own copy of Mono, but this itself is broken out of the box, and the easiest fix is to just install the mono-complete package, which sticks it here) EDIT: I just noticed @Lattyware has an open pull request for custom mono path, which would supersede this.

• Conditionalising all progress bar action on the runtime environment not being the Linux Unity Editor

• Changing the guard conditions on the error handler to silence the (hopefully harmless and presumably idiosyncratic-to-Linux) length-1-inscrutable-character error. We might be able to do this more cleverly than checking the message length, like seeing if the first character is in the standard ASCII character set. If you're happy that Inklecate isn't ever going to try and legitimately return emojis or whatever to STDERR, this seems like a reasonable guard condition.

• Default to Run Inklecate With Mono being true in Ink Settings, conditional on the runtime environment being Linux Unity Editor. I can’t think of any possible set of circumstances in which Linux users wouldn’t want this selected, unless they want the nostalgia of scratching their heads over Win32 errors.

This would cover all the gotchas I came across when running the plugin on Linux. @tomkail – are you happy with that as a self-contained set of changes? Any questions, comments, complaints or suggestions? @Lattyware – do you have any other potential Linux pitfalls to add?

[tomkail]

Seems the 1 character error is a unity 2017 and explains the issues other have had too. Fixed and merged, so that's only the first and third on your list left, which I'll leave for you since I can't test them.

[gboulard]

just got that same "Ink Compiler timed out" error (for the Assets/Plugin/Ink/example/Ink/story.ink file) and i'm on Windows ... so seems not specific to Linux.
this was during unity launch while a lot fo 3D heavy assets where imported, don't know if it has a link with this error or not.

[tomkail]

Ah yeah, that can happen when unity recompiles mid ink-compile. Presumably if you compile again it works? I'm not too bothered about fixing since it's not that important and I suspect it's a bit tricky to work out how to fix it, if its even fixable; but it might be worth noting it as an issue and leaving for the community.

…

On Thu, 25 Jan 2018 at 09:28, gboulard ***@***.***> wrote: just got that same "Ink Compiler timed out" error (for the Assets/Plugin/Ink/example/Ink/story.ink file) and i'm on Windows ... so seems not specific to Linux. this was during unity launch while a lot fo 3D heavy assets where imported, don't know if it has a link with this error or not. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#45 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABMd0MjzCZogExzyViv0mfMSpS0qEQYpks5tOElMgaJpZM4REVCZ> .