grpc-gateway runtime version conflict - grpc-go

from last few days the protoc generator is generating code with v2 version of github.com/grpc-ecosystem/grpc-gateway. I want to keep using github.com/grpc-ecosystem/grpc-gateway v1.16.0. I am unable to remove the v2 version which is causing conflict. I tried removing from go.mod, clearing from $GOPATH. I suppose my protoc generator is not able to use v1 version. Kindly guide me as how shall I sync the grpc-gateway runtime package.
Using below commands to generate the messages and service
protoc -I . --go-grpc_out=. api/protobuf-spec/catalog_fetch/*.proto
protoc -I . --grpc-gateway_out=logtostderr=true:. api/protobuf-spec/catalog_fetch/*.proto
Note: It is generating both grpc.pb.go file and pb.go file, which is further causing issue.
cannot use mux (type *"github.com/grpc-ecosystem/grpc-gateway/runtime".ServeMux) as type *"github.com/grpc-ecosystem/grpc-gateway/v2/runtime".ServeMux ```

I have spent 3 hours debugging the exact same problem.
You have to remove the binary from your GOPATH and GOROOT.
For simplicity, just use which protoc-gen-grpc-gateway.
This should point you to the binary protoc is using under the hood. Remove it and rerun go get -u github.com/grpc-ecosystem/grpc-gateway/protoc-gen-grpc-gateway#v1.16.0.

I think you have installed the v2 version of the generator. Unfortunately, you cannot use v1.16.0 with newer versions of the go protobuf generators. If you want to keep using v1.16.0, you can download the generator from the releases page https://github.com/grpc-ecosystem/grpc-gateway/releases/tag/v1.16.0.

Related

How to download an older version of PyTorch Geometric in Google Colab?

Question: How can I download an older version of PyTorch geometric in google colab?
Context: I am trying to use/load a pytorch-geometric graph and am getting the error message: "RuntimeError: The 'data' object was created by an older version of PyG. If this error occurred while loading an already existing dataset, remove the 'processed/' directory in the dataset's root folder and try again." This graph was generated during summer 2021.
I am using PyTorch and the following code to import Pytorch geometric, but am still getting the error when using older versions.
#import torch
!pip install torch==1.8.0
import torch
torch.__version__
!pip install torch-scatter torch-sparse torch-cluster torch-spline-conv torch-geometric -f https://data.pyg.org/whl/torch-1.8.0+cpu.html
I am not sure whether I am using the correct older version of pytorch-geometric (I don't really know how to check whether this is correct). Any insight to would be greatly appreciated:
How to download older version of pytorch geometric?
What is causing this error?
Thanks in advance.
You may not need to downgrade: If G is a graph data object giving this error you can simply convert it as follows.
from torch_geometric.data import Data
G = Data(**G.__dict__)
I'm not sure if you still need it but I just ran into the same problem and here's what I found:
It seems like there isn't a compatibility document but you can check the version history here and find the corresponding release for the one nearest to the time when your pytorch version was released, of course this doesn't guarantee compatibility but I think you have a pretty good chance?
For the additional packages e.g. torch-scatter, you can find the corresponding versions here and install from the .whl files.

Docstrings are not generated on Read the Docs with Sphinx autodoc and napoleon extensions

I am using the Sphinx autodoc and napoleon extensions to generate the documentation for my project (Qtools). This works well on my local machines. I am using Sphinx 3.1.2 (or higher). However, when I build the documentation on Read the Docs (RTD), only text added directly to the reStructuredText files that form the source of the documentation is processed. The docstrings that are supposed to be pulled in by autodoc do not appear in the HTML documentation generated by RTD. So for example in docs\source\section2_rsdoc.rst I have:
Response spectra
================
The response spectrum class
---------------------------
.. autoclass:: qtools.ResponseSpectrum
:members:
Response spectrum creation
--------------------------
.. autofunction:: qtools.calcrs
.. autofunction:: qtools.calcrs_cmp
.. autofunction:: qtools.loadrs
See also :func:`qtools.convert2rs` (converts a power spectrum into a response spectrum).
This results in:
Response spectra
The response spectrum class
Response spectrum creation
See also qtools.convert2rs (converts a power spectrum into a response spectrum).
In other words, all directives are apparently ignored, and hyperlinks to other functions are not added. I have examined several basic guidance documents such as this one, but I cannot figure out what I am doing wrong. RTD builds the documentation without any errors or warnings. In RTD advanced settings I have:
Documentation type: Sphinx HTML
Requirements file: requirements.txt
Python interpreter: CPython 3.x
Install Project: no
Use system packages: no
Python configuration file: blank
Enable PDF build: no
Enable EPUB build: no
I haven't touched any other settings.
In conf.py I have tried the following variations of line 15: sys.path.insert(0, os.path.abspath('.')), sys.path.insert(0, os.path.abspath('../..')) and the current sys.path.insert(0, os.path.abspath('../../..')). None of those made any difference.
I would be grateful for any help!
RTD builds the documentation without any errors or warnings
This is slightly incorrect. As you can see in the build logs, autodoc is emitting numerous warnings like this one:
WARNING: autodoc: failed to import class 'ResponseSpectrum' from module 'qtools'; the following exception was raised:
No module named 'qtools'
This has happened for all your variations of sys.path.insert, as you can see in some past builds.
Trying to make it work this way is tricky, since Read the Docs does some magic to guess the directory where your documentation is located, and also the working directory changes between commands.
Instead, there are two options:
Locate where the conf.py is located (see How do you properly determine the current script directory?) and work out a relative package from there.
Invest some time into making your code installable using up-to-date Python packaging standards, for example putting all your sources inside a qtools directory, and creating an appropriate pyproject.toml file using flit.

nsys says "please use the qdrep file instead" - huh?

I'm using NVIDIA Nsight Systems version 2019.5.2.16-b54ef97 with CUDA 10.2. I'm running:
nsys profile my_app --some --args=here
so, a plain-vanilla profiling with no funny business. And yet, I get, at the bottom of the output:
... etc. etc. ...
Saving report to file "/some/where/report1.qdrep"
Report file saved.
Please discard the qdstrm file and use the qdrep file instead.
Removed /some/where/report1.qdstrm as it was successfully imported.
Please use the qdrep file instead.
Why am I being told to discard files and use other files instead? Especially given how, eventually, only a single file is generated (a .qdrep file)?
I'm guessing some internal conversion utility is run, and the message is not really intended for me - or am I missing something?
It is just a logging, which is a little confusing though, and later it removes the *.qdstrm file for you automatically.

using cd! in ammonite scripts fails in 0.7.8, worked in earlier version

Using ammonite 0.7.0 using cd! in scripts would change you to that directory and execute the following bit of code, which was great as i've been using ammonite for build & deploy of a scala project.
But in 0.7.8 this does not work any longer, it fails like...
cat TestCd.sc
import ammonite.ops._
import ammonite.ops.ImplicitWd._
cd! root/'Users/'jeff
Error:
TestCd.sc:4: not found: value cd
val res_2 = cd! root/'Users/'jeff
I can make it work in this (very) small test by changing the code to import and instantiate a ammonite.shell.ShellSession, but that leads to other issues.
I've asked on gitter and in github issues, thought i'd cast a wider net as i've not received responses.
Thanks in advance, i don't want to stay on an old version or rewrite the deployment script in a more mature scripting language, as I'm using scala for other things, and feel this is critical to writing shell scripts in any language.
Jeff
While it would be nice if this just worked. An item I missed is that you can install a custom ~/.ammonite/predefScript.sc, and this is how i've gotten around the issue. The contents is identical to predef.sc without the final line. Feel free to grab it from this gist if you need this as well.
predefScript.sc - Gist
Add it to your system with
mkdir -p ~/.ammonite && curl -L -o ~/.ammonite/predefScript.sc https://git.io/v1vv7

Using CocoaPods with Parse is giving me error ”duplicate symbol _PFConfigParametersRESTKey"?

Currently, I am in the middle of migrating my iOS app from api.parse.com to my own server. In the guide I am following, I am at the point where I need to test the app's functionality with a local Parse Server. Although, setting up a custom Parse Server requires having the latest Parse-SDK, and I am running an older version. I am trying to update my frameworks via CocoaPods. My Podfile is as follows:
# Uncomment this line to define a global platform for your project
# platform :ios, '9.0'
target 'MYAPP' do
# Uncomment this line if you're using Swift or would like to use dynamic frameworks
# use_frameworks!
# Pods for MYAPP
pod 'ParseFacebookUtilsV4'
pod 'Parse'
#pod 'ParseTwitterUtils'
pod 'ParseCrashReporting'
pod 'ParseUI'
target 'MYAPPTests' do
inherit! :search_paths
# Pods for testing
end
end
When I try running the app, I get the following error:
duplicate symbol _PFConfigParametersRESTKey in:
/Users/ME/Library/Developer/Xcode/DerivedData/MYAPP/Build/Products/Debug-iphoneos/Parse/libParse.a(PFConfig.o)
/Users/ME/Library/Developer/Xcode/DerivedData/MYAPP/Build/Products/Debug-iphoneos/Parse/libParse.a(PFConfigController.o)
duplicate symbol _PFConfigParametersRESTKey in:
/Users/ME/Library/Developer/Xcode/DerivedData/MYAPP/Build/Products/Debug-iphoneos/Parse/libParse.a(PFConfig.o)
/Users/ME/Library/Developer/Xcode/DerivedData/MYAPP/Build/Products/Debug-iphoneos/Parse/libParse.a(PFCurrentConfigController.o)
ld: 2 duplicate symbols for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I've been searching for something online to help, but nobody seems to be experiencing this problem. I think my case is unique, as I have yet to see someone who has two duplicate errors on the same symbol pointing to the same archive(libParse.a) with one shared file (PFConfig.o) and two differing ones (PFConfigController.o and PFCurrentConfigController.o). I've implemented a variety of solutions that would generally solve this "duplicate symbol" error, but I haven't had any success.
Things I have done:
Ensured that all manually added versions of these frameworks have been removed from the project.
Scanned the project directory up and down multiple times via Finder/Command Line/grep/find and could not find any duplicated frameworks.
Ensured I did not add any "import *.m" files accidentally.
Checked for red files/duplicates in the Frameworks folder as well as the "Link Library With Libraries" section of "Build Phases."
Checked my framework, header, and other linker paths and they seem to be alright. My "Other Linker Flags" contains "$(inherited)" and a -force_load call to a third party ".a" file for analytics.
Cleared ~/Library/Developer/Xcode/DerivedData as well as removed Pods/ and ran "pod install" multiple times.
I went on to investigate the problem in the Parse files. The only place where PFConfigParametersRESTKey is defined is here and here. This seems alright since one of them is preceded by the extern keyword(reference here). I tried messing with the source files a little bit by making this variable not static and also trying to rename one of them. Nothing worked. I cannot figure out where to look to fix this.. If anybody can shed some light here I would greatly appreciate it! Thank you.
The solution to my problem was to remove an -ObjC flag from the linker config. For some reason, -ObjC was not one of the entries in the Linking section of Build Settings. The way I found it was by going to Pods/Pods-MYAPP.debug.xcconfig, and manually removing the -ObjC flag from the OTHER_LDFLAGS variable.