E605: Exception not caught: broken cached binary path file (Maybe Apple Silicon CPU Issue?)

[raphaelluethy]

Machine: Apple MbPro M1 Max OS: Ventura 13.3.1 (Apple Silicon)

Issue: When I try to call either call nvimhs#start('Users/<USERNAME>/Documents/projects/<PROJECT_PATH>', 'snips', []) or add vim.cmd([[call nvimhs#start('Users/<USERNAME>/Documents/projects/<PROJECT_PATH>', 'snips', [])]] to my init.lua file I get the error mentioned in the title. My 2 co-students, which work on the same plugin as me, have no issues (they also have Intel Chips, one uses mac one uses windows).

I did cabal install and stack build, also stack clean and then stack build but with no luck.

I also separatly created the test plugin according to the setup guide in my ~/.config/nvim folder and tried to run it, without any luck.

The error in neovim looks like the following:

I also tested if it was my package manager, so I tested Lazy and Packer, which both created the same error (both also tested with a minimal config setup to prevent any interference from other plugins).

I also completly fresh installed ghcup and update xcode, neither did fix it.

I compared the folders where the plugin executable is saved, only the folder x86_64-osx is differently named, I tried copying the folder and renaming it but that also didn't work

The executable itself seems to be fine:

Location: /Users/<USERNAME>/Documents/projects/<PROJECT_PATH>/.stack-work/install/aarch64-osx/8395b2d08d3f211e35d86ecf54ed4c34d88491ed5d632473a3ea0f08238153f4/9.2.7/bin

If you need any additional information please tell me, I will see that I provide it.

[raphaelluethy]

I managed to find a workaround:

In the nvim-hs.vim package I removed the caching functionality

function! nvimhs#start(workingDirectory, name, args)
    try
        let l:chan = remote#host#Require(a:name)
        if l:chan
            try
                " Hack to test if the channel is still working
                call rpcrequest(l:chan, 'Ping', [])
                return l:chan
            catch '.*No provider for:.*'
                " Message returned by nvim-hs if the function does not exist
                return l:chan
            catch
                " Channel is not working, call the usual starting mechanism
            endtry
        endif
    catch
        " continue
    endtry
    let l:starter = get(g:, 'nvimhsPluginStarter', {})
    if len(l:starter) == 0
        let l:starter = nvimhs#stack#pluginstarter()
    endif

    let l:Factory = function('s:buildStartAndRegister'
                \ , [ { 'pluginStarter': l:starter
                \     , 'cwd': a:workingDirectory
                \     , 'name': a:name
                \     , 'args': a:args
                \     }
                \   ])
    call remote#host#Register(a:name, '*', l:Factory)
    return remote#host#Require(a:name)
endfunction

Then you just to provide the link to the bin itself, in my case: call nvimhs#start('/Users/<USERNAME>/Documents/projects/<PROJECT_PATH>/.stack-work/install/aarch64-osx/8395b2d08d3f211e35d86ecf54ed4c34d88491ed5d632473a3ea0f08238153f4/9.2.7/bin ', 'snips', [])

[saep]

I can't reproduce the issue on my Linux machine.

I have never used a Mac before. But the wrong directory name aarch64-osx vs x86_64-osx indicates an issue with the architecture that stack has built an executable for. The first directory contains an ARM executable (or more generally things compiled for ARM) and the second an X86_64 executable.

The weird error message might indicate that an executable for ARM is run in an X86_64 context or vice versa. I've never seen the error before, though, so I'm just guessing.

The default plugin starter tries to start the executable by simply concatenating the output of stack path --local-install-root with /bin/name (name is the second parameter of nvimhs#start.

What's the output of ls -l "$(stack path --local-install-root)/bin/" in the plugin directory?

Or is the architecture in the output of stack path always consistent (e.g. all paths contain aarch64-osx and not x86_64-osx) ?

[raphaelluethy]

Hello there, thank you for your reply and I'm very sorry for the late response.

Here is the output:

I also checked the stack path, and it seems like it is always aarch64-osx I made a screenshot with the count of the words in stack path

[saep]

One last guess from me that can be checked quickly:

If stack is run from within neovim, it might think it's running on an x86 architecture.

Other than that, I don't think I can help figure this out. :S

[raphaelluethy]

Sorry for asking, how would I check that? Or what would you need to see if that was the issue?

[saep]

Open a terminal in neovim with :terminal and run stack there.

[raphaelluethy]

Does this help?

[raphaelluethy]

Hello @saep , I managed to find the issue: My initital setup for haskell was using ghcup, which in turn seemed to install the x86 dependencies. I now removed the folder and used brew install haskell-stack which made everything work.

Thank you so much for your support, I hope you didn't have to waste too much time but still I want to let you know that I appreciate you very much! :) Keep up the good work 💪

[saep]

It's great that you've figured this out!

I haven't spend much time on this as I also didn't really know what to do.

Thank you for your kind words!