170% CPU usage on 32 cores shouldn't be a lot. Using typical load metrics,
this is about 5% per core. The load reporting for "all of the computing
power is being used at max capacity" should be 3200% in your case. Of
course it depends on your reporting tool.
On Thu, Apr 14, 2022 at 4:50 PM Aleh
>From your workspace, you're in control of which build switch you're
passing. Disable the offending flags. Feel free to inspire yourself from
the current setup grpc uses for building using bazel:
https://github.com/grpc/grpc/blob/master/.bazelrc
This looks like you didn't close recursively and/or installed openssl's
development files on your system.
On Wed, Jul 28, 2021 at 7:56 PM 欧阳昊 wrote:
> Hi, when I execute the command build and locally install gRPC, Protocol
> Buffers, and Abseil:
> $ cd grpc
> $ mkdir -p cmake/build
> $ pushd
So these build instructions don't have any issue for me on an Ubuntu 20.04,
as they are the default build instructions. What next step is failing for
you?
On Sun, May 30, 2021 at 10:09 PM Ugur Ortac
wrote:
> Im using QT Creator 4.15 QT base 5.15
> OS: Ubuntu 20.04 LTS
>
> GRPC Installation
How did you compile? What's the build system? Do you have a reproduction
case we can look at?
On Sun, May 30, 2021, 15:42 Ugur Ortac wrote:
> I have a project that uses GRPC in it.
>
> This working with one of the older GRPC swarms.
>
> But this not compiling when I download and install the
I would direct you to
https://github.com/grpc/grpc-community/blob/master/grpc_ecosystem.md for
details on how to proceed, but, in short:
- transfer of ownership is a very straightforward process using github:
https://docs.github.com/en/github/administering-a-repository/transferring-a-repository
-
Hi,
While the idea is interesting and has merit, adding a libusb dependency
into a network-oriented library seems counter productive and would likely
complexify our build, test, distribution, and maintenance burden. This
seems like an endeavor that'd be much more appropriate as a specific fork;
Also, if your system crashes or becomes unresponsive, it usually means
you've overloaded your computer. The `make -j` command will spawn many
subprocesses to build faster. Try either specifying a number there (like
`make -j 4`), or removing the `-j` option altogether, in order to impose
less load
Your problem is you need to read up on asynchronous programming in
JavaScript, such as
https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous/Introducing
The grpc_web call is setting up a callback, and the reason the code jumps
around is that the code isn't being run yet. It will
These two things have very little in common. One is a RPC system, the other
is a UI system. There's not really anything we have off the shelve we could
share with you that talks about both specifically. What would you be
looking for exactly?
On Friday, January 29, 2021 at 8:33:45 AM UTC-8
The grpc-core library isn't public API. There is no guarantee of stable API
from it. Also, multi-threading is necessary for a variety of reasons, and
it isn't possible to disable it.
You may want to check https://github.com/Juniper/grpc-c
On Sat, May 2, 2020 at 8:13 AM Денис Ваксман
wrote:
>
You should try with a cflags from your workspace, something along these
lines: https://github.com/grpc/grpc/blob/master/tools/bazel.rc
On Wed, Apr 1, 2020 at 3:31 PM wrote:
> guys,
>
> I am using openssl 1.1.1d and I want to have
> DOPENSSL_API_COMPAT=0x10101000L
> in building grpc tsi with
I don't think you've shared what operating system you were using?
On Fri, Mar 27, 2020 at 1:09 PM 'Mya Pitzeruse' via grpc.io <
grpc-io@googlegroups.com> wrote:
> Migrating to @grpc/grpc-js seems to have resolved this. Port bindings on
> the above addresses appear to work fine. It does make me
When designing the gRPC API, we did not find this to be a common needs
feature, no.
While inspecting other common APIs for doing, say, HTTP requests, while
libcurl or python's http client do provide a source address, this isn't
present in nodejs' socket class, or in Ruby's Net::HTTP - not without
The trick here is that there's no official Bazel BUILD file for OpenSSL.
There's still ways to build OpenSSL using bazel, but I find it a bit iffy:
https://stackoverflow.com/questions/58094591/build-makefile-target-in-bazel/58106111#58106111
On Tue, Mar 3, 2020 at 3:55 PM 'Richard Belleville'
We should direct people towards Bazel as much as possible for the
quickstart, especially since the ./tools/bazel script should be fine for
Linux and windows even if Bazel isn't installed.
On Thu, Feb 27, 2020, 16:07 Patrice Chalin wrote:
> Hi Philip,
>
> I've started reviewing the grpc.io
I mean... we've been adding a lot of features recently with regards to
things like xds, changed nanopb to upb, moved from using C to C++, adding
abseil as a dependency, and others. I'm not completely surprised that this
would result in a size increase. Similar things have been noted with the
We're using cloudflare exactly for the reason not to have any sort of
geographic restriction, and hence we don't really have any control over
this. The webserver is not ours, it's cloudflare's.
On Mon, Feb 17, 2020 at 6:17 PM 'April Kyle Nassi' via grpc.io <
grpc-io@googlegroups.com> wrote:
> Hi
ped)
>>
>> Use --sandbox_debug to see verbose messages from the sandbox
>> In file included from external/upb/upb/port.c:2:
>> external/upb/upb/upb.h:12:10: fatal error: 'stdarg.h' file not found
>> #include
>> ^~
>> 1 error generated.
&
We're not Bazel 2.0 ready yet.
On Sun, Feb 2, 2020 at 2:33 PM wrote:
> I tried building it with v1.26.0 tag instead of v1.25.0, and now I get the
> following error -
>
> $ ~/private/bazel-2.0.0-linux-x86_64 build :all
> Starting local Bazel server and connecting to it...
> DEBUG:
>
We currently do not have any pluggable transport layer exposed, no.
On Mon, Jan 20, 2020, 09:28 wrote:
> Hello !
> I am looking for possibility to write custom 'channel' of communication in
> C#. I need to use grpc over something else than HTTP. Is there any
> possibility to write own Server ?
This probably should be an issue filed on github.
On Sun, Jan 19, 2020 at 9:36 PM wrote:
> My project already has abseil-cpp, which works just fine in my external
> directory and the following in CMakeLists.txt
> add_subdirectory(abseil-cpp EXCLUDE_FROM_ALL)
>
> If I then also add grpc, I get
We do not have any plans for DPDK, no.
On Thu, Nov 28, 2019 at 12:25 AM wrote:
> Hi,
>
> I have tried to search some key word in the code. It seems that there is
> no "dpdk" related word in the code base.
> I just want to make sure, is DPDK supported in current DRPC release?
> If not, is there
Getting some sense of the errors you're getting would be useful.
I would suggest first trying to get a normal .exe running, which can then
be something you adapt to your specific usage case.
On Monday, November 25, 2019 at 4:00:17 PM UTC-8, scha...@artandlogic.com
wrote:
>
> Need to write a
This rather looks like a protobuf build failure, not a grpc one.
Try installing protobuf separately, to try and narrow the issue down.
On Tue, Nov 19, 2019 at 7:21 AM wrote:
> I'm trying to install the gRPC on an arm32 device. I'm having compilation
> problems that prevents the complete
You're basically making the case for why deadlines are mandatory.
https://grpc.io/blog/deadlines/ -
The example you're linking is very simplistic, and doesn't follow this
deadline rule, but is aimed at showing a very simple boilerplate on how to
issue an RPC, which is always a difficult balance
We have no plans for that, and the current codebase is way too intertwined
with posix to ever work on FreeRTOS / lwip. A full third party
implementation of grpc would be needed for that at this point.
On Tue, Aug 20, 2019 at 10:23 AM jaehong park wrote:
> Hello Dharam,
>
> I'm having a similar
We have no plan on supporting powerpc, as we can't properly test on it.
On Sun, Aug 18, 2019 at 10:58 PM kumar raja
wrote:
> Can someone please respond to this question?
>
> On Saturday, 17 August 2019 08:39:15 UTC+5:30, kumar raja wrote:
>>
>> I am trying to compile grpc on Power PC arch (Open
1) Yes. protobuf doesn't guarantee ABI compatibility (because C++) across
minor versions of protobuf. When using protobuf, you need an exact match
between the version of protoc used to generate your C++ code, and the
version of libprotobuf. This is the reason why the Makefile will always
chose to
Actually, no, it won't work on an ESP32, not in the current form of the
codebase. There's way too much memory and C++ requirements for it.
On Wed, Jun 5, 2019 at 10:42 AM 'Carl Mastrangelo' via grpc.io <
grpc-io@googlegroups.com> wrote:
> We don't support C directly; it is only used to interact
We can start with this: for C++, protobuf doesn't offer ABI compatibility
on minor releases. Meaning that if you generate code with protobuf version
3.n, it won't work against protobuf version 3.n+1. This naturally extends
to gRPC. That being said, gRPC doesn't necessarily has a strong requirement
With bazel still not being stable (current version being 0.24), its API is
subject to change rapidly and it's difficult for us to keep up to date. As
a result, our current bazel files are really going to work fine with bazel
0.23.2 at the moment. Buyers beware.
This being said, integrating
The test suite should be runnable through bazel. You ought to be able to
run bazel test //test/... and get the desired behavior this way. Right now,
we're only working properly with bazel 0.23.2. If you can't run bazel, you
might also be able to run our test suite using the "run_tests.py"
$ node ./openssl-example.js
This may narrow your spelunking down a bit.
On Wed, Apr 17, 2019 at 3:23 PM Maciej Pijanowski <
maciej.pijanow...@3mdeb.com> wrote:
>
>
> On 17.04.2019 16:56, Nicolas Noble wrote:
>
> OpenSSL is supposed to be provided by your nodejs runtime.
OpenSSL is supposed to be provided by your nodejs runtime. If the file
you're building can't find this symbol at runtime, it means your nodejs
runtime isn't providing its necessary dependencies properly.
Where does this runtime come from?
On Tue, Apr 16, 2019 at 5:28 AM Maciej Pijanowski <
You need to understand the fact that http2 is a single stream that can
contain a lot of streams. It's not going to be a single file descriptor per
rpc, but rather, you are going to potentially have a lot of in-flight rpc
on a single http2 connection. Therefore you may have lots of threads
waiting
Does this happen if you try to install protobuf separately? This most
likely seems a protobuf issue than a grpc one.
On Wed, Mar 27, 2019 at 10:51 AM 'Penn (Dapeng) Zhang' via grpc.io <
grpc-io@googlegroups.com> wrote:
> Is it the same error as described in
>
We do not have a debian package, no.
On Sun, Mar 10, 2019, 10:49 wrote:
> Is grpc c++ easy installation via apt-get supported?
>
> Wanted to avoid compilation from scratch for grpc c++ which is time
> consuming.
>
> Thanks!
>
> --
> You received this message because you are subscribed to the
99% of the time, a pure virtual method call exception is caused by a
use-after-free, either in our code or yours.
This being said, this version is fairly old, and it might be worth
upgrading to see if there's any difference.
On Thu, Dec 13, 2018 at 7:16 AM solomon lifshits
wrote:
> Hello.
> We
There's nothing special we're doing with our symbols at runtime, so it
should be safe to follow standard industry practices when stripping grpc
and/or protobuf-based binaries or libraries.
On Thu, Dec 20, 2018 at 11:44 AM wrote:
> Hello All,
>
> Is there any guidance on DOs and DONTs of using
Unfortunately, we do not have expertise on building redhat packages. This
one would be up to the community to take care of.
On Mon, Dec 17, 2018, 14:15 Hi
>
> We've long since dispensed with using PECL/PEAR for installing PHP
> extensions, but are now forced to do so enable gRPC. The
The short answer to "why provide both" could be resumed to "so that people
have options". There are pros and cons to each build mechanism that is, and
cmake doesn't necessarily fit everyone's needs. There's consumers of the
Makefile that is, such as the Ruby or the Python build, which can't call
There's nothing special to do. Any gRPC server from any language should be
able to natively handle many different clients from many different origins
without any special handling.
On Thu, Nov 1, 2018 at 5:51 AM wrote:
> how to create a server to consume messages from multiple clients in
>
In the C core, this is done using verify_peer_options
On Thu, Sep 27, 2018, 16:09 wrote:
> Hi all,
>
> I tried gitter without luck so I am allowing myself to send my question
> here.
>
> I am using grpc using TLS, and I would like to retrieve the server
> certificate on the client side (ideally
We definitely have some plans, yes. We're in the planning and designing
phase at the moment, and we'd be more than happy to hear about your
requirements and current pain points, in order to integrate these in our
plans.
On Fri, Sep 14, 2018 at 12:55 PM Feng Xiao wrote:
> +Nicolas No
/grpc/examples/cpp/helloworld$
>
>
> But
>
> jay@Nembuntu:~/grpc/examples/cpp/helloworld$ protoc --version
> libprotoc 3.6.1
>
>
> jay@Nembuntu:~/grpc/examples/cpp/helloworld$ protoc --version | grep
> libprotoc.3
> libprotoc 3.6.1
>
>
> Could it be that the* -q *in th
At that point, your issue is with protobuf, not with grpc. I'd suggest
following their own installation instructions separately at
https://github.com/protocolbuffers/protobuf/blob/master/src/README.md
On Thu, Sep 13, 2018 at 11:19 AM Simon Chamlian
wrote:
> Hi,
>
> Previously I installed grpc
You need to toggle requesting the certificate from the client for the
property to appear.
Basically, if you look at this constructor:
https://github.com/grpc/grpc/blob/master/include/grpcpp/security/server_credentials.h#L57
You'll notice the default is "GRPC_SSL_DONT_REQUEST_CLIENT_CERTIFICATE".
Yes, it's definitely doable to cross compile for ARM - in fact we do it
regularly for some of our prebuilt binaries.
Now each environment and case is different. What steps are you following
exactly?
On Thu, Aug 30, 2018 at 9:05 AM Mark Fine wrote:
> Hi!
>
> We're having issues cross compiling
You can make these individual targets if you want to avoid building the
whole repository; the dependency tree should be properly set up for this.
The other aspect as well is that the hello world example doesn't use SSL,
so you can also reduce the overall list of dependencies by using the
https://github.com/grpc/proposal/pull/96
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to
https://github.com/grpc/proposal/pull/94
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to
There is absolutely no way gRPC can work on Arduino in its current form,
and probably will never be. First, gRPC requires either posix network
sockets, or windows sockets. Arduino - and most other microcontrollers -
only have LWIP, and we don't have a port for this. Second, the core is
written in
Bonjour Arnaud,
The answer to your question really depends on what you really need and
want. The pure javascript version of grpc isn't released yet, and when it
is, it will be in alpha state. We won't support anything else than basic
grpc client features at first, but we're planning to listen
You can't build all of gRPC without protobuf 3.0. The specifics are that
you can use gRPC directly without protobuf, or with an older version of
protobuf, but you won't be able to use all the C++ coating we have to use
protobuf, you'll have to provide something else yourself, which isn't
So you are in that bad situation where you have a local version of
protobuf, but your pkg-config doesn't know about it. Try overriding
HAS_PKG_CONFIG to false:
make HAS_PKG_CONFIG=false
this will force the detection to happen using invocation of the protoc tool
instead of relying on
Actually, this doesn't really seem related to arm per-se. This feels like a
normal bug in our dependency tree for the ares dependency. You should be
able to bypass this one (if it hasn't been fixed yet) by actually
installing the c-ares library on your system.
On Friday, December 22, 2017 at
The nanopb dependency is for the core to send some healthcheck messages and
potentially load-balancing. It's not intended to be used by end users as it
is.
It is also theoretically possible to use grpc in plain-C, but we don't have
any good example nor API to do this. However, Juniper had one
The latest version of gRPC should really no longer be .1 due to API/ABI
changes. Are you by any chance trying to run an older binary while hoping
to run against a newer version of the library ? Can you check the filename
that gets installed during the make install step of gRPC ?
On Friday,
This is definitely not on our list of officially supported platforms, and I
never heard anyone attempting this before, but feel free to attempt, and
let us know of the results!
On Wednesday, November 15, 2017 at 9:21:54 PM UTC-8, Kiran Tavadare wrote:
>
> I want to build gRPC C++ library on
The solution I would offer is something along these lines: the client does
a streaming call "ListenForInstructions" and the server responds to it with
a stream of "Instruction" messages.
On Sun, Aug 13, 2017 at 9:48 AM, Tim Hughes wrote:
>
>
> I have been trying to work this
e with the error and it compiled / generated without any problem.
> I also could compile and run the helloWorld example. Maybe there is a bug
> in the script here ?
>
> Am Montag, 7. August 2017 19:55:58 UTC+2 schrieb Nicolas Noble:
>>
>> Try running with the environment var
needed SSL. But since I'm only using grpc in insecure mode I figured
> out I could use the static libraries that are "unsecure" versions of grpc,
> bypassing my entire problem.
>
> torsdag 27. juli 2017 09.12.30 UTC+2 skrev Nicolas Noble følgende:
>>
>> You can disab
You can disable building boringssl by specifying EMBED_OPENSSL=false, but
you'll need to provide headers for it.
On Jul 26, 2017 09:30, wrote:
> Hello!
>
> I'm trying to compile an application linked against webrtc and grpc, both
> of which use their own builtin
Which scenario have you identified that leads to a thread exiting ?
On Tue, Jul 25, 2017 at 4:41 AM, Mos Yud wrote:
> ,Hi
>
> .I am using GRPC 1.4.0 on windows
>
> :According the code, accepting new connection goes like this
>
> *:Thread1*
> *...*
> closure_exec_thread_func
>
one binary. I have a project that includes both
> Python and Go code, and I want to generate all the GRPC stubs from one call
> to protoc. Is that possible without doing the process I suggested?
>
> Sean
>
> On Tue, Jul 11, 2017 at 12:23 AM Nicolas Noble <pixel.no...@gmail.com>
SIGSTOP is usually a debugging signal. That doesn't really look like a core
dump, this just looks like normal debuggging to me. Are you sure this is
the coredump ?
On Sunday, June 25, 2017 at 6:20:13 PM UTC-7, jinyi.s...@gmail.com wrote:
>
>
> Hi experts,
>
> I meet a weird core dump when I try
CXXFLAGS).
> I indeed previously tried to pass -stdlib=libc++ to the linker, but used
> LDFLAGS by mistake. Passing LDXX as you proposed solved the problem.
>
> Thanks!
> Alex
>
>
> On Tuesday, July 11, 2017 at 10:19:17 AM UTC+3, Nicolas Noble wrote:
>>
>>
The grpcio package contains a binary that is both protoc and the plugin,
all in one. So while it technically doesn't contain a binary called
"grpc_python_plugin", you don't need it when using the tools packages we
are providing. The point is that you don't need to have any hassle with
fiddling
It would probably help if you would describe the exceptions you are
getting, and describe your problem better in general.
Answers to these questions may already help: "Sometimes throwing
exceptions" isn't really helpful. How frequent is it ? What are you doing
that would cause one or the other ?
olas! I tried too many to make it work and as a result, my
>> repository was full of junk. I just deleted entire repository and cloned it
>> again. I can successfully build GRPC's example with bazel now.
>>
>> But my own example (https://bitbucket.org/xyyk/grpc-example/ov
gt;
> If I run the command as is, i.e. first cd into __main__, and then use exec
> env - bazel-out., my terminal crashes immediately. I don't know where I
> can find any error log about the crash.
>
> The interesting thing is if I modify this command by a little. I still cd
&
So, first, you can't just grab a portion of the tree and expect it to work
elsewhere. What's important is that it's able to find the WORKSPACE file
properly. So your second test with the copy wouldn't work without a proper
WORKSPACE file. Plus some of the examples are referring to files down the
rpc*.so.1.
>
> On Sunday, April 26, 2015 at 9:03:16 PM UTC+2, Nicolas Noble wrote:
>>
>> That's why then. This is fixed in the master branch.
>>
>
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe
Could you file a github bug for this ? That's definitely something to
assign to a couple of people here.
On Fri, Jun 23, 2017 at 7:52 PM, John Coffey wrote:
> I tried building gRPC v1.4.0 with Visual Studio 2017 and I encountered the
> following error, any ideas? I am using
That being said, grpc_inet_ntop should be used instead then.
On Fri, Jun 23, 2017 at 1:31 PM, Nicolas Noble <pixel.no...@gmail.com>
wrote:
> Do you mean that the file third_party/cares/cares/inet_ntop.c ceases to
> exist ? There are Windows vs Linux reasons for not using inet_nto
Do you mean that the file third_party/cares/cares/inet_ntop.c ceases to
exist ? There are Windows vs Linux reasons for not using inet_ntop
directly. See src/core/lib/iomgr/socket_utils.h for instance, with the
implementations
in src/core/lib/iomgr/socket_utils_common_posix.c,
We don't have any official support nor plan for OCaml as of yet, and I am
not aware of any third party support either.
On Fri, Jun 9, 2017, 08:32 wrote:
> Hello,
>
> I don't find support for OCaml here http://www.grpc.io/about/#osp
>
> Nor can i find it in google.
>
> Any one
For us to be able to help a bit more with your issue, we'd need to
understand how you built grpc and protobuf before. All signs are pointing
at the fact you've built protobuf for 32 bits whereas the rest is building
for 64 bits, but without more details it's hard to tell.
On Tuesday, May 16,
The gRPC base protocol should always be backward compatible. If you have
problems having a 1.2.4 connecting to a 1.0.1 server, this is a bug. Please
describe a bit more your environment (language, platform, etc...) and what
problem you actually see.
On Fri, Apr 14, 2017 at 1:00 PM, Yaz Saito
Just like with basically everything else, I'd expect that only when
exaggerating with the compiler, with excessive templating or code
generation for instance. C++ in itself doesn't generate more code than C
for the same piece of code. It's what you do with the code that does.
On Mon, Apr 3, 2017
https://github.com/grpc/grpc/blob/master/INSTALL.md
On Sun, Apr 2, 2017, 21:49 Mike Lee wrote:
> Hello,
>
> I am trying to fiddle with this project so I can learn C better with a
> real project however I am extremely confused with the build process of this
> project.
Ping ? Do we have any update on the status
of https://github.com/grpc/proposal/pull/13 and the JRuby effort in general
?
On Monday, March 6, 2017 at 2:04:53 PM UTC-8, Jason Lunn wrote:
>
> 1) I agree that a Java wrapper is preferred, and I'd contemplate a JNI
> approach only the wrapper
Does the forked child do any gRPC call at all ? Also, which language ?
On Tue, Mar 7, 2017 at 9:40 AM, AK wrote:
>
> I am trying to make grpc server a daemon by forking a child and making it
> exit. But after that the client handshake starts to fail.
>
> E0307
Ping - any updates on our concerns?
On Feb 16, 2017 17:40, "Nicolas Noble" <pixel.no...@gmail.com> wrote:
> Personally, I wouldn't see Kailash's last comment as a minor comment as he
> says; this is a major problem with that gRFC: deciding between JNI or Java,
> and out
Personally, I wouldn't see Kailash's last comment as a minor comment as he
says; this is a major problem with that gRFC: deciding between JNI or Java,
and outlining the details of how to actually implement an API that would be
compatible with the current one is a design decision that needs to be
Also what's the platform requirement? I think these numbers are from
Linux...
On Wed, Feb 8, 2017, 08:53 'Carl Mastrangelo' via grpc.io <
grpc-io@googlegroups.com> wrote:
> It is if you optimize your code. What kind of latency / throughput
> numbers are in your requirements?
>
>
> On Wednesday,
quot;)
> endif()
>
> so, yes, the cmakelists build system requires Go.
>
>
> 2016-10-07 17:43 GMT+02:00 Nicolas Noble <nno...@google.com>:
>
>> Wait. The cmakefile itself doesn't require to have go. What's going on
>> exactly? Is it the cmakefile of boringssl
:147] check for
>>> SO_REUSEPORT: {"created":"@129032.543473000","description":"SO_REUSEPORT
>>> unavailable on compiling system","file":"/home/osboxes/
>>> code/git/test/server/externals/grpc/src/core/lib/iomgr/
&g
Before getting to the custom endpoint stuff, may I ask why the normal code
doesn't work ? Maybe some subtle alterations to the current code might
help. We haven't tested on every single flavor of Linux around, so maybe
there's an oversight.
On Wed, Oct 5, 2016 at 11:19 PM, Robert Bielik
D'oh, thank you, I didn't spot that he was directly using ld instead of gcc.
On Wed, Sep 7, 2016 at 12:28 PM, Lars Seipel wrote:
> On Mon, Sep 05, 2016 at 01:05:04PM +, Pietro wrote:
> > arm-phytec-linux-gnueabi-ld
> > : unrecognized option '
> >
Transports need to be supplied the proper endpoint, and not the other way
around. So the idea is that you can supply your own endpoints to the C core
if you want when calling into grpc_create_chttp2_transport. See for example
channel_create.c - you could write your own channel code that'll
Can you describe which version of the code you're using ? This seems a bit
odd, given we have stress testing in place that shows we can handle load,
but I couldn't make sense of these line numbers in 1.0, so I am assuming
you're on an older version.
On Sunday, September 4, 2016 at 9:52:22 PM
ng at the Makefile I can see load of lines using the
>
> $(Q) (quiet ?)
> $(E) (echo ?)
>
> Which I have never seen, are they built-in make functions ?
>
> Is there a way to tell make to show me the full compiler's output ?
>
This is a typical trick used by various Mak
Unfortunately, Jack question was about the golang version of grpc, so these
don't apply here :-)
We'll get someone from the grpc-go team to reply here.
On Sat, Aug 27, 2016, 17:17 Paul Grosu wrote:
>
> Hi Jack,
>
> So I believe a lot of this stuff might not yet be documented
ldAndStart(void)"
>>>> (?BuildAndStart@ServerBuilder@grpc@@QEAA?AV?$unique_ptr@VServer@grpc@
>>>> @U?$default_delete@VServer@grpc@@@std@@@std@@XZ)
>>>> 1>grpc++.lib(create_channel_internal.obj) : error LNK2019: unresolved
>>>> external symbol &qu
The grpc API is stable now since 1.0, so distributing generated sources,
while not recommended, sound work. But you should consider distributing the
proto alongside anyway. Maybe someone wants to communicate with your
service in another language than Java?
On Aug 26, 2016 08:10, "Paul Johnston"
We do have some plans to expose this in the future, as part of the public
API, but since our internal API changed and evolved much over time, and
still does, we didn't want to freeze it just yet, as we don't want to force
ourselves to commit to something that could still be improved.
When we are
virtual __cdecl grpc::Channel::~Channel(void)"
>>> (??1Channel@grpc@@UEAA@XZ) referenced in function "public: virtual void
>>> * __cdecl grpc::Channel::`scalar deleting destructor'(unsigned int)"
>>> (??_GChannel@grpc@@UEAAPEAXI@Z)
>>> 1>grpc++.lib(cr
It depends on your platform. But basically, you need to use and
authenticate with the gcloud command line tool, which will create the token
for you that will be read by grpc automatically.
See https://cloud.google.com/sdk/gcloud/reference/auth/login about how to
do that.
On Wed, Aug 24, 2016,
1 - 100 of 105 matches
Mail list logo