Something has caused my Rust language tools to stop working as expected recently. I hadn't been in a Rust file for about 2 weeks, came back and I no longer have all the diagnostic info from the language server in the buffer. No gutter hints, no underlines, no LSP-Saga goodness. Oddly I still have some inlay hints. ?? I could use some help troubleshooting where to dig on this.
Nvim version:
NVIM v0.8.0-1210-gd367ed9b2
LuaJIT 2.1.0-beta3
Packer installs related to rust:
nvim-lspconfig (though not using it to configure rust, see tools below)
Mason and mason-lspconfig
simrat39/rust-tools
Rust-Analyzer and codelldb installed through Mason and updated
So far I have tried removing rust-tools and and configuring through lspconfigs. No luck. I also confirmed with :LspInfo that the language server is running and attached with both config options. I removed LSPSaga, combed through everything touching vim.diagnostic and turned things off / back on, no love there either.
The strange thing is I still have my Typescript, Lua, Svelte and Go support, full featured and totally unchanged, so it's more than likely something specific to Rust. I did run PackerSync a few times because I was playing with themes and saw some updates on other plugins that I didn't pay a lot of attention to. No new issues on any of the github repos related to Rust either, at least not with this issue. Something changed somewhere, but I could definitely use some direction tracking it down.
Any thoughts?
Edit
I was able to get partial support back. I did this by uninstalling the language server with Mason, then installing an older version directly within linux and adding it to $PATH. At this point things some of the things turned back on, but not all. I then removed the binary from $PATH and reinstalled the latest version with Mason, and the things that started working again kept working.
This one has me stumped, but I got enough functionality back to work comfortably again.
I recently started exploring npm and installed a github repo yoonic/nicistore.
But when I try to build it fails.
My question is if I start building things on top of node, which I see has tooo many dependencies from different vendors, Am I completely on the mercy of the respective package developers?
I have seen that most node based github repos fail to build in the first try. If I update one of the modules by running a console command, Is it likely to break all the application?
And if It is does, doesn't it prove node.js an unreliable and unstable development platform?
Think of it as the opposite of most other languages.
You are writing an app in Java.
You want to use LibA, LibB and LibC.
So you try to use LibC 2.4, and as soon as you do, your manager throws all kinds of errors at you.
Why?
Because LibB is using LibC 1.9
So now what are your options?
Strip out all of the calls to all of the new API for LibC that you wanted to use...
...or hope that LibB is open-source, and you can contribute an update for a new version of it, so that you can use the latest version of LibC (and hope it doesn't update).
So now you've done that... but now you've broken your LibA, because it wants the old LibB.
You didn't even want LibA, you just had to have it for your app to be happy with your framework, and the libs that you did actually want to use (B and C). LibA is closed-source, and isn't maintained, anymore. Tough luck. Go back to your old ways, and forget about how much better life could be, if you could only use your framework with the new version of LibC. Or start praying that your framework does a major rewrite, to get rid of the LibA dependency... but then figure out what new hell you have to deal with, just to get LibC working.
Is this really better than Node?
What node allows you to do is install dependencies which are at different versions than the same library that your dependencies are using.
Not that you can't do that with Java, too... but the entire community has decided that it's just not ever going to try to do that, and thus outlaw it at a tool level.
Next, you see too many things which leave you at the mercy of too many vendors...
Going back to Java (or C++, or nearly any mainstream language), looking at Java, itself, how many libraries are made by Sun Microsystems, or by James Gosling?
Moreover, if you want to boil it down, to suggest using only, say, one huge, overarching framework (like Spring MVC) and using no other libraries of any kind (like JodaTime), then how many libraries does Spring itself lean on, and why are they of no concern to you, even if you're just using the compiled VM bytecode?
In fact, a strong argument could be made to be more wary of compiled binaries, in languages where it was traditional to see strong, copy-left licensing like that of the GNU GPL... in that realm, you open yourself up to craziness.
Most of the Node stuff, by comparison, is dirt-simple freeware. And even if it's not, it's quickly replaceable as most are micro-libraries.
I would suggest that updating a Node package your server depends on, via CLI is less hazardous than doing the same to a full-fledged Java project, if your goal is to see your project compile again, some time in the next week, but with the newer fixes/features...
...but if you're talking about a full-scale, production application, you also want to be cognizant of what it is you're doing, with regards to your codebase, regardless.
As to why things don't build for you on the first try, assuming that you're on a non-Windows platform, and your environment is up to date, I don't know.
Most C/C++ projects I clone don't build for me, first try, either. I usually forget something, or there was something poorly documented, or the actual project was set up to make unfair assumptions about the system it would operate in.
Does that mean that C++ is an unreliable/unstable development platform?
Or the hours/days spent on getting Eclipse set up in an enterprise environment, with all kinds of crazy, company-specific projects and project settings?
It sounds like a case of bad design, more than anything.
Then again, most of my projects these days are wrapped in Docker containers. They all run in the same environment, whether they're running in Windows, on a Mac, or on the server. That tends to take the sting out of building projects, regardless of what language the code is in, or what VM / processor they're running on.
You should also be using NPM shrinkwrap files, or Yarn Lockfiles to preserve the build configuration, with the known-working versions of libraries. And you should have unit and integration tests to ensure that changing library versions has no discernible impact on your system.
As you can see here, while a Sentry project has a setting for platform, it has instructions (sections to the left) for connecting any platform to its logging:
Furthermore it works when logging from multiple programming languages, and it's not obvious in the stream, which errors are from which programming languages until you go to the individual error.
Is the platform setting just marking a project as one language, so you may have one project for Python, one project for JS, etc. or are there more important ramifications of changing the "platform" of a project? I saw in the changelog that "Sentry will now ask for your project’s platform." since 5.2 although it isn't clear what this option is for, as it will apparently log from any language's Raven logger.
This is the best answer I've found (and it's still pretty vague):
This is mostly so we can apply some sane defaults on how to render the stack frames visually.
We definitely don't prevent you from sending a JavaScript error to a project that is set to Python, for example.
I'm a good Java programmer, albeit the first languages I learnt were C/C++. Anyway, for work reasons, I switched to Java and web languages. Sometimes I get interested in this or that Linux project, usually coming as a git or svn repository... The problem is that I usually clone the repo, I try to configure it, I install all the needed libraries (and this takes ages), maybe finally I succeed... but then make fails or configure itself fails, complaining about some tool that is missing. Or maybe I installed two versions of the same library and the configure script gets the wrong one, or boring problems like this.
Anyway, I see loads of people using those tools everyday, so it must not be so difficult after all!
Can you point out resources that may help in the first steps?
Thanks
What you are referring to are known as autotools and make
autotools are used to generate scripts and build files that can be used to build as well as install a program/package/software (whatever you call it)
Here is wikipedia link for the GNU build system in general.
And refer to this link for details about the autotools and related stuff
It may take longer, but if you are interested in how to fix those problems yourself I recommend learning how autoconf and automake work. I made a positive experience with the book "Autotools: a practitioner's guide to Autoconf, Automake and Libtool". I read the dead-tree version but it is also available online: http://fsmsh.com/2753.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Subversion has a superb client on Windows (Tortoise, of course). Everything I've tried on Linux just - well - sucks in comparison....
Disclaimer: A long long time ago I was one of the developers for RabbitVCS (previously known as NautilusSvn).
If you use Nautilus then you might be interested in RabbitVCS (mentioned earlier by Trevor Bramble). It's an unadulterated clone of TortoiseSVN for Nautilus written in Python. While there's still a lot of improvement to be made (especially in the area of performance) some people seem to be quite satisfied with it.
The name is quite fitting for the project, because the story it refers to quite accurately depicts the development pace (meaning long naps). If you do choose to start using RabbitVCS as your version control client, you're probably going to have to get your hands dirty.
Generally I just use the command line for svn, it's the fastest and easiest way to do it to be honest, I'd recommend you try it.
Before you dismiss this, you should probably ask yourself if there is really any feature that you need a GUI for, and whether you would prefer to open up a GUI app and download the files, or just type svn co svn://site-goes-here.org/trunk
You can easily add, remove, move, commit, copy or update files with simple commands given with svn help, so for most users it is more than enough.
To begin with, I will try not to sound flamish here ;)
Sigh.. Why don't people get that file explorer integrated clients is the way to go? It is so much more efficient than opening terminals and typing. Simple math, ~two mouse clicks versus ~10+ key strokes. Though, I must point out that I love command line since I do lot's of administrative work and prefer to automate things as quickly and easy as possible.
Having been spoiled by TortoiseSVN on windows I was amazed by the lack of a tortoisesvn-like integrated client when I moved to ubuntu. For pure programmers an IDE integrated client might be enough but for general purpose use and for say graphics artists or other random office people, the client has to be integrated into the standard file explorer, else most people will not use it, at all, ever.
Some thought's on some clients:
kdesvn,
The client I like the best this far, though there is one huge annoyance compared to TortoiseSVN - you have to enter the special subversion layout mode to get overlays indicating file status. Thus I would not call kdesvn integrated.
NautilusSVN,
looks promising but as of 0.12 release it has performance problems with big repositories. I work with repositories where working copies can contain ~50 000 files at times, which TortoiseSVN handles but NautilusSVN does not. So I hope NautilusSVN will get a new optimized release soon.
RapidSVN is not integrated, but I gave it a try.
It behaved quite weird and crashed a couple of times. It got uninstalled after ~20 minutes..
I really hope the NautilusSVN project will make a new performance optimized release soon.
NaughtySVN seems like it could shape up to be quite nice, but as of now it lacks icon overlays and has not had a release for two years... so I would say NautilusSVN is our only hope.
kdesvn is probably the best you'll find.
Last I checked it may hook in with konqueror, but its been a while, I've moved on to git :)
You could also look at git-svn, which is essentially a git front-end to subversion.
See my question: What is the best subversion client for Linux?
I also agree, GUI clients in linux suck.
I use subeclipse in Eclipse and RapidSVN in gnome.
IMHO there is one great svn gui client, SmartSVN. It is commercial project, but there is foundation version (100% functional) witch can be used free of charge, even for commercial purposes. It is written in java, so it is multi-platform (it requires sun-java* package) http://smartsvn.com
I guess you could have a look at RabbitVCS
RabbitVCS is a set of graphical tools written to provide simple and straightforward access to the version control systems you use. Currently, it is integrated into the Nautilus file manager and only supports Subversion, but our goal is to incorporate other version control systems as well as other file managers.
RabbitVCS is inspired by TortoiseSVN and others.
I'm just about to give it a try... seems promising...
For Ubuntu you cane make use of KDESVN integrated with Nautilus to five a Tortoise SVN Feel.
Try this ClickOffline.com : Ubuntu alternatives for Tortoise SVN
Nobody else has mentioned it and I keep forgetting the name so I'm adding these instructions here for my future self the next time I google it...
currently pagavcs seems to be the best option.
you want one of these .deb files
sillyspamfilter://pagavcs.googlecode.com/svn/repo/pool/main/p/pagavcs/
(1.4.33 is what I have installed right now so try that one if the latest causes problems)
install then run
nautilus -q
to shutdown nautilus, then open up nautilus again and you should be good to go without having to logout/shutdown
Sadly rabbit just chokes on large repos for me so is unusable, paga doesn't slow down browsing but also doesn't seem to try and recourse into directories to see if anything has changed.
I'm very happy with kdesvn - integrates very well with konqueror, much like trortousesvn with windows explorer, and supports most of the functionality of tortoisesvn.
Of course, you'll benefit from this integration, if you use kubunto, and not ubuntu.
Take a look at SVN Work Bench, it's decent but not perfect
sudo apt-get install svn-workbench
I sometimes use kdesvn for work directly against a repository.
I often use Subclipse when working on projects via Eclipse.
But most of all I use good ol' CLI. With some aliases and bash scripts to back it up, it really is the most concise, reliable method of using svn.
I have tried NautilusSVN (no relation to NaughtySVN) and svn-workbench and found them too problematic or lacking in functionality. I know I tried RapidSVN at some point but I must not have been impressed as it was quickly uninstalled, but I don't remember anything about it.
If you use it, NetBeans has superb version control management, with several clients besides SVN.
I'd recommend however that you learn how to use SVN from the command line. CLI is the spirit of Linux :)
If TortoiseSVN is really ingrained you could try using it through WINE? Though I haven't tried it.
Failing that, I've found Eclipse with Subversive to be pretty good.
If you use eclipse, subclipse is the best I've ever used. In my opinion, this should exist as stand-alone as well... Easy to use, linked with the code and the project you have in eclipse... Just perfect for a developer who uses eclipse and wants a gui.
Personally, I prefer the command-line client, both for linux and windows.
Edit: if you use XFCE and its file manager (called Thunar), there's a plugin which works quite well. If I don't want to open the terminal, I just use that one, it has all the functionality, is fast and easy to use. There's also one for git included, though...
Nautilus provides context menu for svn activities
sudo apt-get install nautilus-script-collection-svn
cp -r /usr/share/nautilus-scripts/Subversion ~/.gnome2/nautilus-scripts/
For more info
Nautilus context menu
As a developer, I use eclipse + sub-eclipse client (Assuming that you are using svn to checkout some development project and you will compile them).
most people don't spend much time with svn operation, and command line is the fastest way to do so.
there is also some nice GUI tools :
http://rabbitvcs.org/
or
http://www.harecoded.com/nautilus-subversion-integration-tool-execute-svn-commands-with-gnome-scripts-96355
Since you're using Ubuntu, and not Kubuntu, I assume you're using GNOME. You might be interested in Nautilus Subversion Integration described on that link.
Anjuta has a built in SVN plugin which is integrated with the IDE.