why is this linux only?

[alok]

what are the technical limitations to at least mac support?

[michaelb]

It's more like "will not work on windows".

Mac has its chances, actually, since it's UNIX. Problems comes with path & file manipulation, that's a pain to do in general in a UNIX+windows compatible way.

That being said, sniprun's interpreters often need to write to temporary files, create a temp executable and sometime run a program (ex; the python intrepreter). If anything is too different, it won't work, but I'm actually confident it should work ok in most cases on Mac.

There is also the issue with the precompiled binary: Sniprun has a Rust executable at its heart and using the precompiled (for linux by myself) one will not work on Mac. So Mac users should have the Rust toolchain and follow the instructions in the install section to compile the binary locally, so that's not a big issue, but for starters one should mind this quirk.

All in all my compatibility disclaimer is more about my not being able to test anything on Mac or Windows.

You're welcome to try for yourself of course, or even contribute to the project (be it fixes, tests, or even CI Mac integration :-) )

[michaelb]

If you could confirm at least some of the functionnality works ok on Mac, and which steps you had to take to achieve that, I'll be happy to update the README in consequence

[alok]

From what you described, virtually certain it works on Mac. Will check

On Mon, Apr 5, 2021 at 3:46 AM Michael B @.***> wrote:

If you could confirm at least some of the functionnality works ok on Mac, and which steps you had to take to achieve that, I'll be happy to update the README in consequence

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/michaelb/sniprun/issues/54#issuecomment-813333334, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB7QUTC7WGSI2BQ7YGHB72LTHGIHZANCNFSM42MABVMQ .

[michaelb]

hate to be pushy, but it's been 2 days and it'd be wonderful news if mac support could be confirmed :-)

[yingzhu146]

@michaelb for me (M1) it doesn't work. No response when running SnipRun. No errors/messages submitted - just no response. Installation was successful as far as I can tell. Let me know how to debug best.

[michaelb]

Okay, M1 is still another story (because this is 100% certain the precompiled binary WON'T be compatible)

This symptom is exactly what happens when the core (a rust binary) cannot be executed.

Did you try installing with bash ./install.sh 1? (You'll need the Rust toolchain) (Or run cargo build --release from the plugin root directory but that may be less convenient)

You should see a message 'compiling blah blah (most bleeding-edge etc...)' instead of 'downloading sniprun binary' at post-install

Also, an output of :checkhealth sniprun might help debugging.

I'll soon include a message so that the validity of the binary in regards to the platform appears in the checkhealth

[yingzhu146]

Yeah Rust toolchain is working, I've compiled many of my CLI tools from source for the M1. I've tried both versions (bash ./install.sh and cargo build --release) from clean installs. (Also - many rust binaries work well under rosetta in my experience even if its x86).

here you go:

health#sniprun#check
========================================================================
## Installation
  - OK: `tree-sitter` found  0.19.4 (89e1157a299596f3ce2155ba9fd69d5e2c03d3e6) (parser generator, only needed for :TSInstallFromGrammar)
  - OK: sniprun binary found
  - OK: Rust toolchain found

My rust knowledge is limited (but I'm confident to help dig) - I've also built simple lua nvim plugins so happy to help debug.

Thanks a ton for the package and the help!

[michaelb]

Well, if even compiling from source doesn't work, i don't really know...

Just a little detail, there is bash ./install.sh (download) and bash ./install.sh 1 (compile), the later should be equivalent to cargo build --release as post-install script.

If you could try to clone this repository, build and execute locally (cargo test -- --test-threads=1 <- many will fail if you don't have the relevant language installed though, and nvim -c "set rtp+=." -u plugin/sniprun.vim <testfile> ), that may provide data about why it doesn't work right.

I will admit right now, I haven't got a clue* on what has gone wrong and how to potentially fix it, and I really hope cargo will spit some output like 'please use --option'.

* except if you didn't properly clean the plugins or the (incorrect) binary, but you mentionned you did clean installs.

[yingzhu146]

Turns out I DID mess up the installation :)

Plug 'michaelb/sniprun', {'do': 'bash install.sh 1'}

and it works like a charm for a simple c example (might be worth adding to readme?)

Now what would be beyond amazing is if we could display the result of previously executed lines like nvim-hlslense displays the grey search counts here

I think then we'd have a hydrogen on steroid replacement.

EDIT: I should probs add a new issue with feature request

Again can't thank you guys enough for this awesome work gonna be a game changer for my workflow!

[michaelb]

AL-RIGHT 😎!!

That's very good news, and the relevant info is on its way to the README now it's confirmed it works.

I'll also update the ./install.sh script so it won't let mac users install a binary that doesn't work.

For the highlight stuff, that's really a super idea, but that belongs to a new issue /feature request (i'll open one up sometime today if you don't). It doesn't seem too hard hopefully.

Edit: look around the different interpreters (:SnipInfo, :SnipInfo <name>) because some of them may be even more interesting than you think (Lua-nvim for lua plugin dev, Python3_jupyter for a seamless notebook-like experience)

[michaelb]

Closing since Mac (and even M) compatibility has been confirmed and relevant changes are in dev, en route for the next PR (soon, i hope)

[Leandros]

There is no reason this should not work on Windows. Nothing you described is Linux specific and most of the challenges are even solved by the Rust standard library.

[michaelb]

@Leandros Well there's no 'one killer reason' this can't work on windows.

(Nota bene: 'interpreter' is sniprun jargon for the module in charge of a language)

However, there are several things that make me hesitate. Starting with the most important ones:

• Hard to develop : I don't have a convenient way to develop for windows. VM are a thing sure, but I just can't develop as efficiently, with my own setup (definitely linux-only) on windows and setting up a full environment with shared directories etc... isn't trivial , so it's a path of frustration for me. Moreover, sniprun is not my most important project anymore.

• Feature parity : Some things (fifo-based REPL interpreters, in particular) will require a complete overhaul, and because they're such fragile and capricious creatures, I'm less than sure we could reach feature parity....while I personally consider REPL-enabled interpreters the most important sniprun feature (even though I perfectly know there's only a handful on them now: I'd rather spend effort into making say, a linux-only Rust REPL-capable interpreter, rather than a multiplatform standard Rust integration)

• additional complexity : Some things (crates for xdg dirs) may be windows compatible, some others (hardcoded paths and Command::new("") ) will require some changes, the build & deploy process will have to support both Unixes and Windows, for a fair share of additional complexity.

• demand : is there really such a "market share" ? I've never seen a neovim user on windows IRL.

However, I'm not opposed to supporting windows. Sniprun is quite documented, it's possible for someone exterior to make a PR for this

[michaelb]

no activity for over a year. I've seen one neovim user that required windows compatibility for all their plugins since then, so definitively not a lot. I'll be closing this as "won't do"