Mac m1 Sonoma - FSautocomplete not working

[jhartum]

Version

0.66.1+b13b6e75bdf47112b55bebf6153ef1b618746cbf

Dotnet Info

.NET SDK: Version: 7.0.403 Commit: 142776d834

Runtime Environment: OS Name: Mac OS X OS Version: 14.0 OS Platform: Darwin RID: osx-arm64 Base Path: /usr/local/share/dotnet/sdk/7.0.403/

Host: Version: 7.0.13 Architecture: arm64 Commit: 3f73a2f186

.NET SDKs installed: 7.0.403 [/usr/local/share/dotnet/sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 7.0.13 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 7.0.13 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found: None

Environment variables: Not set

global.json file: Not found

Learn more: https://aka.ms/dotnet/info

Download .NET: https://aka.ms/dotnet/download

Steps to reproduce

dotnet tools install -g fsautocomplete dotnet fsautocomplete --adaptive-lsp-server-enabled ( or dotnet fsautocomplete)

Details

not working

Logs

[15:50:21.166 ERR] [Startup] Start - LSP mode crashed System.AggregateException: One or more errors occurred. (Header does not end with expected character sequence: q) ---> StreamJsonRpc.BadRpcHeaderException: Header does not end with expected character sequence: q at StreamJsonRpc.HeaderDelimitedMessageHandler.ReadHeadersAsync(CancellationToken cancellationToken) at StreamJsonRpc.HeaderDelimitedMessageHandler.ReadCoreAsync(CancellationToken cancellationToken) at StreamJsonRpc.MessageHandlerBase.ReadAsync(CancellationToken cancellationToken) at StreamJsonRpc.JsonRpc.ReadAndHandleRequestsAsync() --- End of inner exception stack trace --- at Ionide.LanguageServerProtocol.Server.startWithSetup[client](FSharpFunc2 setupRequestHandlings, Stream input, Stream output, FSharpFunc2 clientCreator, FSharpFunc2 customizeRpc) in /_//src/LanguageServerProtocol.fs:line 183 at Ionide.LanguageServerProtocol.Server.start@286-2.Invoke(FSharpFunc2 customizeRpc) in /_//src/LanguageServerProtocol.fs:line 286 at FsAutoComplete.Lsp.AdaptiveFSharpLspServerModule.startCore[a,a](a toolsPath, FSharpFunc2 workspaceLoaderFactory, ISourceTextFactory sourceTextFactory) in /home/runner/work/FsAutoComplete/FsAutoComplete/src/FsAutoComplete/LspServers/AdaptiveFSharpLspServer.fs:line 5093 at FsAutoComplete.Parser.lspFactory@154.Invoke(Unit unitVar0) in /home/runner/work/FsAutoComplete/FsAutoComplete/src/FsAutoComplete/Parser.fs:line 154 at FsAutoComplete.Lsp.AdaptiveFSharpLspServerModule.start(FSharpFunc2 startCore) in /home/runner/work/FsAutoComplete/FsAutoComplete/src/FsAutoComplete/LspServers/AdaptiveFSharpLspServer.fs:line 5132

Checklist

• [X] I have looked through existing issues to make sure that this bug has not been reported before
• [X] I have provided a descriptive title for this issue
• [X] I have made sure that that this bug is reproducible on the latest version of the package
• [X] I have provided all the information needed to reproduce this bug as efficiently as possible
• [ ] I or my company would be willing to contribute this fix

[vzarytovskii]

FWIW, tested it just yesterday on the fresh m2, worked quite well. Not sure what's the difference.

[TheAngryByrd]

I think this is all runtime related as we've had a few issues pop up that seem to be m1 specific:

• https://github.com/fsharp/FsAutoComplete/issues/939
• https://github.com/dotnet/sdk/issues/23267#issuecomment-1595760542
• https://github.com/dotnet/sdk/issues?q=is%3Aissue+is%3Aopen+m1

Not sure if we can do anything about it since it seems runtime related. Nor do I have an m1 macbook to test these things.

[TheAngryByrd]

Haven't had my ☕ but looking at the logs, this seems like a normal error if fsautocomplete doesn't receive the correct input. Which editor are you using with fsautocomplete?

[vzarytovskii]

This looks awfully similar to https://github.com/fsharp/FsAutoComplete/issues/1109

I would assume replit uses some derivative of vscode/vscodium?

[TheAngryByrd]

@baronfel i guess this is another case of "should we crash if we get bad data from a client?". Not sure how to gauge this one.

[baronfel]

This is is pretty fundamental protocol-level wrongness, and I think we should crash as a result. There's a difference between well-formed messages that are missing protocol level fields, and not even having well-formed messages.

[baronfel]

Separately, the StreamJsonRpc library has had several revisions ahead of our current version, and the error messages for header parsing have gotten more clear. If we update users might have more of a clear signal about which component is going wrong here.