Closed talentlessguy closed 4 years ago
@talentlessguy
I haven't updated the extension yet; I'm working on automating it so that every gotop release creates a downloadable .so binary, and that everything gets tagged all nicely.
If you want to try this, edit go.mod
in the gotop-nvidia
directory and change the gotop version to v3.5.0. It should work.
@xxxserxxx it is already v.3.5.0
module github.com/xxxserxxx/gotop-nvidia
require (
github.com/GeertJohan/go.rice v1.0.0 // indirect
github.com/facebookgo/stack v0.0.0-20160209184415-751773369052 // indirect
github.com/k0kubun/pp v3.0.1+incompatible // indirect
github.com/mailru/easyjson v0.7.1 // indirect
github.com/rai-project/config v0.0.0-20190926180509-3bd01e698aad // indirect
github.com/rai-project/logger v0.0.0-20190701163301-49978a80bf96 // indirect
github.com/rai-project/nvidia-smi v0.0.0-20190730061239-864eb441c9ae
github.com/rai-project/tegra v0.0.0-20181119122707-1d9901ca382b // indirect
github.com/xxxserxxx/gotop/v3 v3.5.0
)
//replace github.com/xxxserxxx/gotop/v3 => ../gotop
go 1.14
Yes; it's coming down to a path issue for the libraries. I'm making progress on this. Hang tight!
After spending a couple of hours reading ticket reports, I've learned there's no solution. Plugins are too tightly coupled. I'm going to have to provide binaries until the Go team fixes this.
@talentlessguy here's a tarball in the meantime. Current gotop, updated nvidia driver. This should present whatever information is available.
@xxxserxxx I think plugins shouldn't be compiled. They should be used as go packages. Definetely not compiled
@xxxserxxx it drops 404
Huh. It couldn't have expired that quickly, but who knows. gofile.io was temporarily offline so I had to use a different service. Here it is again, and a GPG signature made with the key associated with my Github account, which you can get with:
curl https://github.com/xxxserxxx.gpg
So: download both files to a directory, and in that directory run:
curl https://github.com/xxxserxxx.gpg | gpg --import
gpg --verify gotop-v3.0.0-20200308135020-025527730fb3.tgz.asc
@xxxserxxx the tarball doesn't contain a plugin. I think I will setup the repo by myself not to download everytime
It does; it contains both the executable and the .so. However, I bzipped it rather than gzipped it so the file extension is wrong; rename to tbz2
or just use tar xf
without specifying the compression and (GNU) tar should figure it out. Remember, kids: don't wake up and immediately do computer stuff!
Compiling yourself will be easiest while debugging. When I get back from vacation I need to focus on packaging, but it'd still require you to repeatedly download binaries.
Check out both projects in the same directory, then add the following to the nvidia's go.mod
file just before the go version directive:
replace github.com/xxxserxxx/gotop/v3 => ../gotop
build with:
go build --buildmode=plugin ../gotop/nvidia.so .
Then run the gotop executable from the gotop directory. You don't even need to compile it in that case; you can just:
go run ./cmd/gotop -X nvidia
The network connection here sucks, so the archive finally finished downloading. Either the download got interrupted, or the archive got corrupted on upload, because the file I got was broken. Maybe that's what you're seeing.
Any updates on this?
I need a tarball with both gotop executable and a plugin :)
No. I was hoping for some comment from the Go team to https://github.com/golang/go/issues/31354, but there's been no communication. Several people are talking about it, but only users. Since there's no indication how this will break -- or even whether it's considered a priority, or something we'll limp along with for another couple of years -- I've decided to change my tactic.
I'm a fan of Caddy, and what they've done recently is publish a build tool. This forces everyone who wants plugins to compile their own, which I really hate, but I can't see a way around it until Go addresses the weaknesses in the plugin implementation.
I need to change the extensions API and at the very least document how to build with extensions, and ideaally write the tool to make it easier -- this is going to take a bit of work. First, I want to release a bug fix, so this will come after that. I'm not promising anything, but I may have things shimmed up by 04/19 enough to continue testing on the NVidia extension.
@talentlessguy , since there's been no movement on plugins, I'm taking the Caddy approach for now and using a builder. It does require you to compile gotop yourself, and for that you need Go installed, but it handles the rest of the heavy lifting. Once you download it, you run it (more or less) like this:
$ go run ./build.go -r v4.0.0 -l github.com/xxxserxxx/gotop-nvidia
$ go build -o gotop -ldflags "-X main.Version=v4.0.0-nvidia" ./gotop.go
The first command creates a go.mod
and gotop.go
main file and updates the imports.
I haven't received feedback from any other NVidia folks, so I still don't know how the extension sensor code is working, but let me know if you give it a try.
I'm closing this for now as it relates to the plugin extension code which I'm not using until it is improved in Go.
@talentlessguy , I'm prepping for the v4.0.0 release and have new NVidia code. Would you mind trying it and letting me know how it works (or doesn't)? A binary is available in the gotop-builder project.
This depends on the nvidia-smi
tool.
Thank you.
I tried to compile nvidia.so from gotop-nvidia repo file and then use it in gotop but it threw me an error of an incompatible version
gotop version:
3.5.0
OS/Arch:
GNU/Linux x64
go version:
1.14
Also please copy or attach
~/.local/state/gotop/errors.log
if it exists and contains logs: