I'm guessing your cross compiler setup is somehow mucking up endian logic.
Do you have a simple reproducible set up.
On Apr 28, 2016 2:58 PM, "Brian Savage" wrote:
> I am using protobufs on an ARM processor running Ubuntu Linux. Everything
> seems to be working, except some integers are being pa
How are you determining the end of the encoded protocol buffer? What
language/data type are you using? It sounds to me like you are null
termination (perhaps with a C char*?), which isn't going to work to well
with a binary structure. Decoding with a null byte, particularly for an
integer field, sh
n those differences of opinion lies precisely the
reason why one would "reinvent the wheel": one person's "yet another wheel"
is another person's "train tracks".
On Mon, Mar 25, 2013 at 4:11 PM, Christopher Smith wrote:
> On Mon, Mar 25, 2013 at 4:25 AM,
On Mon, Mar 25, 2013 at 4:25 AM, Vic Devin wrote:
> Oliver,
> yes, Protobuf can do many more other things than simply remoter
> communication, but again my point is that these are all "low level" stuff
> which is again in "the reinventig wheel territory"; if software industry
> wishes to make a g
Interested.
--Chris
On Nov 19, 2012, at 4:07 AM, Ryan Fogarty wrote:
> I have a repeated primitive field array optimization for the protoc-generated
> Java source, but before I discuss I would like to gauge interest (and get
> access to the Protocol Buffer Group).
>
> Thanks,
> Ryan
>
> --
Same way as any other varint wiretype field.
--Chris
On Aug 30, 2012, at 11:23 AM, Sean Nguyen wrote:
> Hi all,
>
> Does anybody know how to implement packed=true option for a list of enum?
>
> Thanks,
>
> Sean Nguyen
> --
> You received this message because you are subscribed to the Google
On Wed, Aug 8, 2012 at 3:08 PM, Eric J. Holtman wrote:
> On 8/8/2012 4:51 PM, Chris Morris wrote:
>> I want to keep STL debugging *for the rest of my project*. This leads me to
>> consider compiling the protocol buffers project without STL debugging info.
>>
>> What are the implications of this?
>
Your doBar(Request) should be codegen'd by a plugin. That's the bug. You should
only be coding against
doBar(Bar).
--Chris
On Jul 25, 2012, at 3:33 AM, proto...@googlecode.com wrote:
>
> Comment #2 on issue 401 by martin.c...@gmail.com: Java generated message
> field getters should return nul
On Fri, Jul 20, 2012 at 5:41 PM, Christopher Smith wrote:
> 4) Plugins have to be exe's. That kind of sucks if the plugin is in a
> scripting language. I was looking at adding logic so that if you use
> the --plugin flag, and if the "executable"'s name ends in .c
Three points:
There isn't much value in your Attributes message, so DummyAttributes2 would be
the way I'd go.
List is probably not an ideal name for an field, as it may overlap with other
names depending on programming language.
Per the style guide, field names should be like_this, not LikeThi
I'm trying, for the first time, to get protocol buffers to work sanely
on Windows. It's proving to be harder than I expected.
Partly, it's my own fault: I'm building the project with VS11-beta,
which I'm sure nobody has bothered to make work (and for good reason,
it is right there in the name: bet
Protobuf is a library for serializing in its own format, not other predefined
binary formats. It is also by design fairly simple with limited integrity
checking features intended to help with backwards and forwards compatibility.
I don't think it can help you with editing Diablo2 files.
--Chris
I have been reworking my Makefile's to do automatic dependency
generation proper. I realized that with modern gcc & GNU make it gets
pretty simple to do this, but protocol buffers were my one stumbling
point, as they have dependencies that gcc can't extract. It occurred
to me that it ought to be tr
This sounds like something *very* weird is going wrong in your runtime. What
does the debugger show as the memory locations of the string fields? the memory
locations the allocator provided for the string data?
I think if you make a stand alone unit test for this, you won't see this
behaviour.
On Apr 4, 2012, at 2:54 PM, Jawaid Hakim wrote:
> My group builds applications using use multiple languages, including Java and
> C#, so a simple int64 for date representation does not work.
That there isn't a simple way to do it is a pretty nasty strike against having
a standard implementati
Nothing prevents you from making a module available for everyone's benefit. If
it is broadly useful, it will undoubtedly be universally adopted.
--Chris
P.S.: What is a "decimal type"?
On Apr 4, 2012, at 2:21 PM, Jawaid Hakim wrote:
> Date and decimal types are ubiquitous and in wide use. La
AFAIK the answer is no. A lot of the value of protocol buffers derives from
keeping their functionality simple. There are plenty of all singing/all dancing
serialization frameworks already. ;-)
I think date in particular is fraught with peril. I'd recommend against
encodung them as strings. Wha
Message objects *don't* have mutators and are conceptually a copy of the
relevant builder object.
--Chris
On Feb 20, 2012, at 10:22 AM, Tom Swirly wrote:
> The documentation says it's immutable:
> http://code.google.com/apis/protocolbuffers/docs/reference/java-generated.html#message
> and th
You could also just specify the static library name and/or use the static link
flag. Not sure why you'd solve this via a rename
--Chris
On Oct 22, 2011, at 10:43 AM, JonathonS wrote:
> Hi all,
>
> is there a way to have protobuf build the libraries with tags? (like
> boost does)
>
> For
You can always modify the compiler with a plugin.
--Chris
On Tue, Aug 23, 2011 at 12:36 AM, Christopher Head wrote:
> Hi,
> Does anyone know if Protobuf's C++ output is ever going to support
> enum classes? I'd like to be able to define the elements of my enum in
> just one place (i.e. in the me
I'm going to assume you aren't trying to use protobuf's as a JNI workaround,
and rather want it as an rpc solution.
I am not aware of a tool that can go from C declarations to protobuf ones. In a
lot of ways, the syntaxes are similar, so it isn't much work to convert from C.
That said, there ar
On Fri, Jul 8, 2011 at 9:46 AM, Eric Hopper wrote:
> I guess. This is an interesting and general problem. Practically every
> system like protobuf needs to solve it. Python itself, for example,
> solves it for pickle by allowing you to write custom methods for your
> classes to reduce them to well
Basic rule: if the memory is used outside the lifetime of the function call,
you don't want it on the stack. Async_write very much requires the memory to be
around later.
--Chris
On Jul 6, 2011, at 10:10 AM, platzhirsch wrote:
> I find it difficult to check this by so many messages. This appr
You could always extend the compiler, but I bet you could get away with a
simple preprocessor that aliases types and represents those larger integers as
raw bytes.
--Chris
On Jun 30, 2011, at 7:30 AM, Eric Hopper wrote:
> I'm building an application around protocol buffers. The types in my
>
I think Gabor wants to avoid the overhead of implementing all that
additional bookkeeping as it'd slow down development. Something that
would effectively generate a protobuf descriptor so that it'd stay
consistent with changes in the Java code.
I would suggest looking at the protostuff project:
h
Best thing is when encoding, group messages by type and preface each group with
a type name and FileDescriptorSet which will allow you to decode the rest using
a DynamicMessage (see notes on self describing messages on the wiki). As per
usual, use coded stream encoding with length prefixing for
Are these POJO's or object generated by protoc? If the former, I would say you
are SOL. If the latter, you can ask the object for its descriptors and actually
dump to protocol buffer version of the .proto, at which point making the .proto
is fairly straightforward.
--Chris
On Mar 18, 2011, at
On Thu, Mar 17, 2011 at 5:22 PM, Henner Zeller
wrote:
> On Thu, Mar 17, 2011 at 02:41, ctapobep
> wrote:
>> So pity protobuf doesn't support inheritance, only because of this I
>> can't use it. Any forecasts, are creators going to add this feature?
>
> There are good reasons not to support inher
On Tue, Nov 16, 2010 at 7:28 PM, Kenton Varda wrote:
> On Tue, Nov 9, 2010 at 10:42 PM, Christopher Smith wrote:
>
>> This aspect could be mostly mitigated by integrating a metadata header in
>> to files. For systems with this kind of an approach look at Avro & Hessian.
>
On Tue, Nov 9, 2010 at 7:56 AM, maninder batth wrote:
> In typical WS-* webservice, WSDL describes a service interface,
> abstracts from underlying communication protocol and serialization and
> deserialization as well as service implementation platform.
> Where does PB fits in this picture? Is
On Mon, Oct 25, 2010 at 4:11 PM, Henner Zeller wrote:
> On Mon, Oct 25, 2010 at 16:10, maninder batth
> wrote:
> > I disagree. You could encode field name in the binary. Then at de-
> > serialization, you can read the field descriptor and reconstruct the
> > field. There is absolutely no need fo
On Tue, Nov 9, 2010 at 6:44 AM, Kalki70 wrote:
> Oh, I just found out that you are the developer. It seems I am not the
> only one who thinks you reinvented the wheel :
>
>
> http://google-opensource.blogspot.com/2008/07/protocol-buffers-googles-data.html
Yes, this is not a new line of thinking
On Tue, Nov 9, 2010 at 6:21 AM, Kalki70 wrote:
> On Nov 9, 10:13 am, multijon wrote:
> > As a side note, the company I worked at used ASN.1 for five years to
> > encode all of its product's communication messages (Using PER
> > encoding), with what was supposed to be a highly optimized
> > imple
On Tue, Nov 9, 2010 at 6:15 AM, Kalki70 wrote:
> On Nov 9, 2:59 am, Kenton Varda wrote:
> > OK, I looked into this again (something I do once every few years when
> > someone points it out).
> >
> > ASN.1 *by default* has no extensibility, but you can use tags, as I see
> you
> > have done in yo
On Mon, Nov 8, 2010 at 9:59 PM, Kenton Varda wrote:
> The bigger problem with ASN.1, though, is that it is way over-complicated.
>
THIS
> It has way too many primitive types. It has options that are not needed.
> The encoding, even though it is binary, is much larger than protocol
> buffer
Might as well use a new object. Creating a new object is if anything likely
less overhead.
--Chris
On Oct 25, 2010, at 1:52 PM, ury wrote:
> Hi!
>
> Is it possible to reuse the same Protobuf object when unserializing a
> large number of objects in Java using the equivalent of the C++
> Parse
On Sun, Oct 17, 2010 at 10:01 PM, nit wrote:
>
> On Oct 14, 4:51 pm, Adam Vartanian wrote:
> > > I have a file which i need to encrypt and send so can i use
> > > protocol buffer for this buffer? please do reply me.
> >
> > Protocol buffers don't provide any built-in encryption or anything
> >
On Sat, Jul 24, 2010 at 3:22 PM, Oliver Jowett wrote:
> Christopher Smith wrote:
> > There is also the other end of the spectrum, where I am at. With a
> > large Hadoop cluster and terabytes of data, the efficient storage and
> > zippy parsing of protobufs is a huge deal.
There is also the other end of the spectrum, where I am at. With a
large Hadoop cluster and terabytes of data, the efficient storage and
zippy parsing of protobufs is a huge deal.
In many ways, protobufs allow you do do what XML promised, but much
more efficiently. The other way to look at them is
You probably need a FileDescriptorSet, which has the whole enchilada.
--Chris
On Jul 23, 2010, at 12:08 PM, David wrote:
> I'm trying to send a self-describing message from a JMS producer to a
> consumer.
>
> On the producer I have something like:
>
>Descriptor desc = builder.getDescr
gt;
> On Mon, May 17, 2010 at 7:59 PM, Christopher Smith wrote:
> This does somewhat suggestive that it might be worthwhile specifically
> tagging a field as ASCII only. There are enough cases of this that it
> could be a huge win.
>
>
> On 5/17/10, Evan Jones wrote:
This does somewhat suggestive that it might be worthwhile specifically
tagging a field as ASCII only. There are enough cases of this that it
could be a huge win.
On 5/17/10, Evan Jones wrote:
> On May 17, 2010, at 15:38 , Kenton Varda wrote:
>> I see. So in fact your code is quite possibly slow
criptor
> classes, so we want to be careful not to mess up that consistency.
>
> Instead of calling toString(), you could call TextFormat.printFieldToString()
> to get a string representation of the field, although it will include the
> field name.
>
> On Mon, May 10
Never seen it before... and the Java code is pretty extensively used. Surely
someone would have hit this before.
--Chris
On May 15, 2010, at 9:03 PM, Igor Gatis wrote:
> Have anyone experienced deadlock problems related to Java protobuf generated
> messages static initialization?
>
> My mult
or *all* of them in some consistent way.
> If we fill them in ad-hoc then they may be inconsistent, and we may not be
> able to change them to make them consistent without breaking users.
>
> On Mon, May 10, 2010 at 9:49 AM, Christopher Smith wrote:
> I noticed EnumValueDescriptor
I noticed EnumValueDescriptor uses the default toString() method. Why not
override it to call getFullName()?
--Chris
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubsc
PB serialization is deterministic, but not necessarily canonical depending on
your canonicalization rules. I imagine that can cause issues. In particular,
fields with default values look different depending on whether the default
value was actually set, and of course the ordering of repeated fie
We do stuff very much like this. Generally we try to encode the PB's as
sequence files so that they are splittable. If that doesn't make sense, then we
use non-splittable coded streams.
--Chris
On Apr 19, 2010, at 9:22 PM, stuti awasthi wrote:
>
> Thanks Jason,
>
> Yes map reduce works with
Is this a case of needing to delimit the input? I'm not familiar with
SplitterInputStream, but I'm wondering if it does the right thing for this
to work.
--Chris
On Thu, Feb 18, 2010 at 12:56 PM, Kenton Varda wrote:
> Please reply-all so the mailing list stays CC'd. I don't know anything
> abo
I hate to quibble on this, but strictly speaking:
for (int i = 0; i < some_vector.size(); i++)
is not perfectly valid unless you have verified that some_vector.size() <
static_cast(std::numeric_limits::max());
This would be broken in cases of a very large vector (possible with a
vector on 32-bi
One compression algo that I thought would be particularly useful with PB's
would be LZO. It lines up nicely with PB's goals of being fast and compact.
Have you thought about allowing an integrated LZO stream?
--Chris
On Wed, Dec 9, 2009 at 12:21 PM, Kenton Varda wrote:
> Thanks for writing this
Given that there is no Java version of protoc, it has been tempting to see
how far one can get with just using FileDescriptorSet's and dynamic
messages. I ended up building this short function for iteratively adding all
the dependencies of a particular Message in to a FileDescriptorSet. While it
wa
Doesn't the UDP packet header effectively provide that length prefix for
you?
--Chris
On Fri, Sep 18, 2009 at 12:26 PM, jayt0...@gmail.com wrote:
>
> One other thing I wanted to say was that I chose to use
> CodedOutputStream to send
> data because ultimately I have to manually encode a length pr
The best way to think of it is:
Builder : Java Message :: C++ Message : const C++ Message
As far as performance goes, it is a common mistake to confuse C/C++
heap memory allocation costs to Java heap allocation. In the common
case, allocations in Java are just a few instructions... comperable to
Heh, I remember complaining about this to James when they first
published the byte code spec. It was annoying then and continues to be
annoying today.
On 7/24/09, Kenton Varda wrote:
> How annoying. I'll make sure this or something like it gets into the next
> release -- which I'm going to try
I'm trying to do some work using dynamic message, working from a
FileDescriptorSet produced by protoc. The heuristic I've come up with is
something like:
Parse the binary in to a FileDescriptorSet
for each FileDescriptorProto in the set
create the FileDescriptor from the FileDescriptorProto
I'd recommend using an atomic swap to do your updates. So you create
your new version of the PB localy, and then swap it in to the memory
location that is visible to all the other threads. The only real
downside is you stress the heap more, and that is probably
cheaper/simpler (particularly if you
No, but in short the advantages over ASN.1 can be summed up as
"simpler, and for most cases, more efficient".
On 6/23/09, Jon M wrote:
>
> Hello,
>
> The system I am currently working on uses ASN.1 at the heart of the
> client/server communication. I am evaluating PB's for another part of
> the
On Thu, 2009-06-18 at 11:44 -0700, jonme...@yahoo.com wrote:
> Hello,
>
> I am new to the Protocol Buffer community and am evaluating it for a
> project I am working on. The project I am working on has a common code
> base that runs on both on a Windows PC as well as an embedded target
> we have
The normal way to do it is to send each Entity as a separate message.
CodedInput/OutputStream is handed for that kind of thing.
--Chris
On Sun, Jun 14, 2009 at 4:14 PM, Alex Black wrote:
>
> Is there a way to start sending a message before its fully composed?
>
> Say we have messages like this:
http://code.google.com/p/protobuf/wiki/RPCImplementations
On Sun, May 24, 2009 at 12:42 PM, SyRenity wrote:
>
> Hi.
>
> Sorry if this was already asked in the past, but does Protocol Buffers
> provide some IPC communication methods?
>
> Or they provide the data encapsulation, and I should use an
61 matches
Mail list logo