davidlday / vscode-languagetool-linter

A from scratch redesign of LanguageTool integration for VS Code.
https://marketplace.visualstudio.com/items?itemName=davidlday.languagetool-linter
Apache License 2.0
158 stars 12 forks source link

FetchError when running under macOS with Apple Silicon / M1 - with solution #504

Closed henrygermany closed 1 year ago

henrygermany commented 1 year ago

Environment & Configuration:

First of all, thanks for the great extension! This is more intended as a Public Service Announcement, rather than an actual bug in the extension software, as the error is with languagetool, not with your extension. I was not sure where to post my solution though, and as I needed to do some digging to find the solution, I figured I should share my experiences.

Describe the bug I installed LanguageTool with homebrew and ran the local languagetool server unter http://localhost:8081, as described in the wiki. When installing the extension and linting some german text, the text didn't get linted and I noticed that the extension produced some errors in the output:

Error connecting to http://localhost:8081/v2/check
FetchError: invalid json response body at http://localhost:8081/v2/check reason: Unexpected token E in JSON at position 0

I looked at the log files of the LanguageTool server under /opt/homebrew/var/log/languagetool/languagetool-server.log and noticed some errors:

java.lang.RuntimeException: Failed to initialize BridJ (java.lang.UnsatisfiedLinkError: Can't load library: /var/folders/t5/w4bvvm8s6kz3vsk72xy56xfr0000gn/T/BridJExtractedLibraries7505944670267179261/libbridj.dylib)
        at org.bridj.Platform.initLibrary(Platform.java:444)
        at org.bridj.Platform.<clinit>(Platform.java:228)
        at org.bridj.Pointer.<clinit>(Pointer.java:208)
        at org.languagetool.rules.spelling.hunspell.DumontsHunspellDictionary.<init>(DumontsHunspellDictionary.java:37)
        at org.languagetool.rules.spelling.hunspell.Hunspell.getDictionary(Hunspell.java:50)
        at org.languagetool.rules.spelling.hunspell.HunspellRule.init(HunspellRule.java:584)
        at org.languagetool.rules.de.GermanSpellerRule.init(GermanSpellerRule.java:1504)
        at org.languagetool.rules.spelling.hunspell.HunspellRule.ensureInitialized(HunspellRule.java:558)
        at org.languagetool.rules.spelling.hunspell.HunspellRule.match(HunspellRule.java:219)
        at org.languagetool.rules.de.GermanSpellerRule.match(GermanSpellerRule.java:1422)
        at org.languagetool.JLanguageTool.checkAnalyzedSentence(JLanguageTool.java:1414)
        at org.languagetool.JLanguageTool.access$1500(JLanguageTool.java:75)
        at org.languagetool.JLanguageTool$TextCheckCallable.getOtherRuleMatches(JLanguageTool.java:1994)
        at org.languagetool.JLanguageTool$TextCheckCallable.call(JLanguageTool.java:1906)
        at org.languagetool.JLanguageTool$TextCheckCallable.call(JLanguageTool.java:1877)
        at org.languagetool.JLanguageTool.performCheck(JLanguageTool.java:1338)
        at org.languagetool.JLanguageTool.checkInternal(JLanguageTool.java:1016)
        at org.languagetool.JLanguageTool.check2(JLanguageTool.java:943)
        at org.languagetool.server.TextChecker.getPipelineResults(TextChecker.java:805)
        at org.languagetool.server.TextChecker.getRuleMatches(TextChecker.java:754)
        at org.languagetool.server.TextChecker.lambda$checkText$5(TextChecker.java:475)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.lang.Thread.run(Thread.java:829)

... etc.

My Solution After some digging, I found out that LanguageTool 5.9 uses a library, BridJ, which, at this point in time, has no binary built for arm64. See here. Apparently, the error got fixed with the languagetool snapshot from 2022-11-26.

I then

I then put the complete path to this jar file under VSCode Settings > Language Tool Linter > Managed > Jar File and set the service type under Settings > Language Tool Linter > Service Type to managed

And voilà, now everything works as expected. I am not sure if my solution was the most elegant, but it works, for me at least.

Sorry if this is the wrong place for this. Again, I was not sure where to put it for other m1 users who maybe get the same error to find it. Maybe there could be a place for it in the docs?

davidlday commented 1 year ago

Thanks for contributing this! I can try to work it into the docs, although I'm not sure how fast that'll happen right now. In the meantime, I do have discussions enabled on the repo. Feel free to start a thread there! Leaving open for now, and updating as a docs item.

henrygermany commented 1 year ago

Thanks for your response and your time! You're right, I should have opened a discussion thread... I don't have anything more useful to contribute at the moment, so I won't open one on the same topic now. If I find something interesting which concerns this, I will. Cheers!