Anyone know why generated C# classes don't include the named constants for
options? (MessageOptions,FieldOptions,etc).
They still work but you have to hard code the number value directly, which
is less that readable and isn't on par with the named constants generated
for the C++ files.
--
You
#x27;d be really surprised if a CRC ended up being more performant than a
single branch to see if the mod message exists if I'm understanding your
situation correctly.
On Mon, Jun 20, 2016 at 3:36 PM, a_teammate wrote:
> Am Montag, 20. Juni 2016 20:50:17 UTC+2 schrie
much
>> simpler logic already introduced or invented to better make protobuf
>> message version independent, if yes we would be happy to hear them!
>>
>> Thanks in advance and for reading all this stuff :)
>>
>> --
>> You received this message because you are subs
ightly more memory?
>
>
> Well: Maybe we totally ask the wrong questions here and theres a much
> simpler logic already introduced or invented to better make protobuf
> message version independent, if yes we would be happy to hear them!
>
> Thanks in advance and for reading all
c.
>
> Any advice, or is there a proper place to file a bug?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to protobu
a choice made
with the encoding and has nothing to do with JSON itself. Do those JSON
blobs also lose forward compatibility when the schema changes?
Thanks for the discussion,
J
On Thu, May 19, 2016 at 7:01 PM, Tim Kientzle wrote:
>
> > On May 18, 2016, at 10:01 PM, Jeremy O
you can use that technique there as well.
>
> Finally, remember that proto2 is not going away: If proto2 assumptions
> are deeply baked into your systems, you can keep using it. protoc will
> continue to support it for a very long time.
>
> Cheers,
>
> Tim
>
>
>
ail to protobuf+unsubscr...@googlegroups.com.
>> To post to this group, send email to protobuf@googlegroups.com.
>> Visit this group at https://groups.google.com/group/protobuf.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You recei
have switched everything back to proto2, which
despite some inconvenience I believe is more feature complete and
superior to proto3 at this time.
On Fri, Mar 18, 2016 at 4:20 PM, 'Feng Xiao' via Protocol Buffers
wrote:
>
>
> On Tuesday, March 15, 2016 at 12:32:07 PM UTC-7, Je
other disadvantages, e.g., extra copies ...
>
> On Fri, Mar 18, 2016 at 6:51 PM, Jeremy Ong wrote:
>
>> Neither are appropriate in my use case unfortunately. I want to be
>> able to tag any message with data in a field range special within the
>> organization. The
, are there
other options or suggestions to handle this?
Best,
Jeremy
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to protobuf+unsubscr...@google
I don't understand. If a message is a simple struct then the generated wrapper
code would populate it with the default as defined by the proto it was compiled
with wouldn't it? Are you suggesting that the implementation on different
platforms would lack the wrapper objects generated by protobuf?
Is it possible to add a field option to select fields within an imported
message? Ie without modifying the original proto file, add custom options to
its fields?
Thanks
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from
That sounds like a poor design decision, and one easily readded without
breaking anything. If a field doesn't have an explicit default, you use 0 or
whatever, thereby not breaking anyone not using them, but if an explicit
default is provided that is used instead. I am using that feature as well.
Does the arena allocator also get used by messages allocated as children of the
root message?
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to protobuf+unsu
Is it possible, given a proto file, but without compiling it(protoc), to use
the proto file directly to be able to load data? In other words parsing the
proto file at run time and generating a reflection interface or something such
that a tool may read the messages with just the proto file witho
What about something like this
message UnknownMessage
{
enum MessageType
{
MESSAGE_TYPE_A = 1;
MESSAGE_TYPE_B = 2;
MESSAGE_TYPE_C = 3;
}
required MessageTypemsgType = 1;
required bytesmsgPayload = 2;
}
On Wednesday, February 10, 2
nding on whether or
not it turns out to badly effect performance maybe do some compiler
modifications myself.
Thanks for the help.
On Thursday, July 19, 2012 8:22:29 AM UTC-5, Evan Jones wrote:
>
> On Jul 18, 2012, at 16:14 , Jeremy wrote:
> > I understand, but if one wants to keep a
ve to involve a
cache miss.
On Tue, Jul 17, 2012 at 1:30 PM, Evan Jones wrote:
> On Jul 17, 2012, at 2:33 , Jeremy Swigart wrote:
> > Is there a way to tell the proto compiler to generate message
> definitions for which the message fields are statically defined rather than
> e
Is there a way to tell the proto compiler to generate message definitions
for which the message fields are statically defined rather than each
individual field allocated with dynamic memory? Obviously the repeater
fields couldn't be fully statically allocated(unless you could provide the
compil
On 05/10/2012 07:52 AM, Evan Jones wrote:
On May 9, 2012, at 15:26 , Jeremy Stribling wrote:
* There are two nodes, 1 and 2, running version A of the software.
* They exchange messages containing protobuf P, which contains a string field F.
* We write a new version B of the software, which
On 05/09/2012 04:41 AM, Evan Jones wrote:
On May 8, 2012, at 21:26 , Jeremy Stribling wrote:
Thanks for the response. As you say, this solution is painful because you
can't enable the optimization until the old version of the program is
completely deprecated. This is somewhat simple i
On 05/08/2012 06:04 PM, Daniel Wright wrote:
On Tue, May 8, 2012 at 4:42 PM, Jeremy Stribling <mailto:st...@nicira.com>> wrote:
I'm working on a project to upgrade- and downgrade-proof a distributed
system that uses protobufs to communicate data between instan
lds of the newer versions.
I'm wondering if anyone has experience with a scenario like this, and
if there's a more elegant way to solve it. If not, what do folks
think of this business of an external translator program? Foolish
nonsense? Worthy of a proper insertion point?
Thanks,
Je
nputs would result in a repeated field in the output containing a
nested
message with an index field and a difference field.
--
Jeremy Leader
jlea...@oversee.net
Kenton Varda wrote:
> What do you mean by "represented with their index"?
>
> I don't understand the problem.
many places.
--
Jeremy Leader
jlea...@oversee.net
The_Glu wrote:
> Hello,
>
> I use the following prototype :
>
> message Find {
>required uint64 tag = 1;
>required Common.Hash peerID = 2;
>required string pattern = 3;
> }
>
> Now:
>
data types.
--
Jeremy Leader
jlea...@oversee.net
Jon M wrote:
> Hello,
>
> I am evaluating using Protocol Buffers for objects that are shared
> across a distributed system. One key thing I would like is a way to
> look at these objects "on the wire" by sniffing
I'm not an autotools expert, but I suspect you're using an inappropriate
version (too old? or too new?) of autoconf and friends. On my system, I
see:
% rpm -q --whatprovides /usr/bin/autoreconf /usr/bin/automake
autoconf-2.59-12
automake-1.9.6-2.1
--
Jeremy Leader
jlea...@oversee.
you want to send to client 2. Serialize
both instances, send instance 1 to client 1, and send the concatenation
of instance 1 and instance 2 to client 2.
That way, there's no double serialization, and each client only gets the
fields you want to send to them.
--
Jeremy Leader
Jeremy Leader wrote:
> Might it be possible to use the XS wrappers generated by protobuf-perlxs
> from Python?
Aaah, not enough caffeine yet. I somehow confused XS (Perl-specific)
with SWIG (supports Perl, Python, and many others). Never mind!
--
Jeremy Leader
[EMAIL PRO
Might it be possible to use the XS wrappers generated by protobuf-perlxs
from Python?
--
Jeremy Leader
[EMAIL PROTECTED]
andres wrote:
> Hi,
>
> I would like to use protocol buffers in my python code but currently
> the serialization and parsing methods are too slow compared
ginal
.proto file, where nodes have references to their neighbors, and you'd
probably need a map from node id to node object reference, which you'd
use during deserialization.
--
Jeremy Leader
[EMAIL PROTECTED]
GDR wrote:
> my bad. The code snippet should be as follows:
>
> for(
I was assuming all the properties of a node (weight, label, color,
whatever) would be in UndirectedGraphNode; UndirectedGraphNodeReference
would only have the id and nothing else.
--
Jeremy Leader
[EMAIL PROTECTED]
GDR wrote:
> Thanks Jeremy. That worked!
> But we now have information
ence {
required string id = 0;
}
message UndirectedGraphNode {
required string id = 0;
repeated UndirectedGraphNodeReference neighbors;
}
message UndirectedGraph {
repeated UndirectedGraphNode nodes;
}
--
Jeremy Leader
[EMAIL PROTECTED]
GDR wrote:
> Hi,
>
> I'm wonder
ewer gcc.
For what it's worth, "make check" is standard in projects built using
Gnu automake (see
http://www.gnu.org/software/automake/manual/html_node/Tests.html).
--
Jeremy Leader
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this mess
35 matches
Mail list logo
