Re: [protobuf] Linker issues: undefined reference to `a_message__get_packed_size'
The author of protobuf-c might not read this list. You might want to e-mail
him directly.
But I would suggest looking at the contents of tut.pb-c.c to see whether it
actually defines a_message__pack. Maybe the problem will be obvious.
On Tue, Dec 28, 2010 at 3:08 PM, Suhail Doshi digitalwarf...@gmail.comwrote:
I am using the protobuf-c extension out there.
Getting the following errors:
gcc tut.c tut.pb-c.c -o tut -lprotobuf-c -lprotobuf -lpthread
/tmp/ccBHwTBl.o: In function `main':
tut.c:(.text+0xab): undefined reference to
`a_message__get_packed_size'
tut.c:(.text+0xcc): undefined reference to `a_message__pack'
collect2: ld returned 1 exit status
tut.c
#include tut.pb-
c.h
#include
stdio.h
#include
stdlib.h
int main(int argc, char **argv)
{
AMessage msg =
AMESSAGE__INIT;
void
*buf;
unsigned
len;
if (argc 2 || argc 3)
{
fprintf(stderr, usage: pack a [b]
\n);
return
1;
}
msg.a =
atoi(argv[1]);
if (argc == 3)
{
msg.has_b =
1;
msg.b =
atoi(argv[2]);
}
len =
a_message__get_packed_size(msg);
buf =
malloc(len);
a_message__pack(msg,
buf);
fwrite(buf, len, 1,
stdout);
return
0;
}
tut-pb-c.h
--
/* Generated by the protocol buffer compiler. DO NOT EDIT! */
#ifndef PROTOBUF_C_tut_2eproto__INCLUDED
#define PROTOBUF_C_tut_2eproto__INCLUDED
#include google/protobuf-c/protobuf-c.h
PROTOBUF_C_BEGIN_DECLS
typedef struct _AMessage AMessage;
/* --- enums --- */
/* --- messages --- */
struct _AMessage
{
ProtobufCMessage base;
int32_t a;
protobuf_c_boolean has_b;
int32_t b;
};
#define AMESSAGE__INIT \
{ PROTOBUF_C_MESSAGE_INIT (amessage__descriptor) \
, 0, 0,0 }
/* AMessage methods */
void amessage__init
(AMessage *message);
size_t amessage__get_packed_size
(const AMessage *message);
size_t amessage__pack
(const AMessage *message,
uint8_t *out);
size_t amessage__pack_to_buffer
(const AMessage *message,
ProtobufCBuffer *buffer);
AMessage *
amessage__unpack
(ProtobufCAllocator *allocator,
size_t len,
const uint8_t *data);
void amessage__free_unpacked
(AMessage *message,
ProtobufCAllocator *allocator);
/* --- per-message closures --- */
typedef void (*AMessage_Closure)
(const AMessage *message,
void *closure_data);
/* --- services --- */
/* --- descriptors --- */
extern const ProtobufCMessageDescriptor amessage__descriptor;
PROTOBUF_C_END_DECLS
#endif /* PROTOBUF_tut_2eproto__INCLUDED */
--
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 unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
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 unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Issue 188 in protobuf: protobuf fails to link after compiling with LDFLAGS=-Wl,--as-needed because of missing -lpthread
Comment #35 on issue 188 by ken...@google.com: protobuf fails to link after compiling with LDFLAGS=-Wl,--as-needed because of missing -lpthread http://code.google.com/p/protobuf/issues/detail?id=188 Thanks! -- 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 unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: protobuffer suport composite object in stack not in heap?
On Tue, Jan 4, 2011 at 9:38 PM, Kenton Varda ken...@google.com wrote:
I think this would be too complicated to integrate into the official C++
implementation. You could, however, write an alternative protobuf
implementation that provides this.
Note that with the official implementation, you can avoid malloc costs by
reusing message objects. A message object never frees any memory until the
top-level object is destroyed, so if you reuse the object to parse multiple
messages, you can avoid a lot of allocation costs after the first message.
A while ago, a colleague had a memory leak reusing a PB message which
contained a repeated field. If I'm not mistaken the problem was that
pb_message::Clear() calls vectorsomething::clear() and string::clear()
which does not really release the memory allocated. I can't really tell for
sure actually.
@Kenton, does that make any sense? If yes, is there a way to avoid it?
You might also experiment with tcmalloc (part of the Google perftools
package) to see if it is faster than your system's memory allocator.
On Wed, Dec 29, 2010 at 10:21 PM, aristohuang pmp...@gmail.com wrote:
eg.
message A {
string a; when set_a(), memory of a in heap(new/malloc)
int b; when set_b(), memory of b in stack
};
if defines many composite sub-class objects, a lot of time cost in new/
malloc. are you think so? or have a good idear for this?
--
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 unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
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 unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
Re: [protobuf] Re: protobuffer suport composite object in stack not in heap?
On Tue, Jan 4, 2011 at 5:25 PM, Igor Gatis igorga...@gmail.com wrote: A while ago, a colleague had a memory leak reusing a PB message which contained a repeated field. If I'm not mistaken the problem was that pb_message::Clear() calls vectorsomething::clear() and string::clear() which does not really release the memory allocated. I can't really tell for sure actually. @Kenton, does that make any sense? If yes, is there a way to avoid it? As Evan says, this is by design. The memory is not leaked -- it will be reused when the message object is reused, and deleted when the message object is deleted. The actual problem that your colleague probably observed is that if you happen to parse one message which is much larger than usual, the object will allocate a bunch of memory for that one large message, and then will keep it around even after parsing smaller messages. So your memory usage is determined by the largest message you parse, rather than by the average. You can also run into problems if you have a message type whose instances vary widely in shape. E.g. if type Foo has optional fields of type Bar and Baz, and you parse one instance of Foo that contains a Bar, then reuse the Foo to parse a message containing a Baz, then the Foo has allocated both Bar and Baz and will hold on to them. Thus the Foo is actually using more memory than was needed for either of the two messages it parsed. In practice these problems can manifest as memory usage that monotonically increases over the life of the process, although the rate of increase slows over time. A way to avoid this problem is to call SpaceUsed() to find out how much memory the object is using at any particular time. Once it crosses some threshold, delete the object and create a new one. Another approach is to reuse each objects at most N times -- this saves most of the allocation costs while preventing memory usage from growing without bound. Of course, all of this applies *only* to C++. Java protobuf objects are not reusable (since they are immutable), and in Python memory is discarded on Clear(). -- 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 unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
[protobuf] Re: Converting JSON Text Into PB Bytes Type
Thanks.
I downloaded the binaries and tried to use the test class but my
compiler couldn't see class protobuf.codec.json.TypesProtoBuf, it's
not anywhere in the binaries. Has this class been added recently but
was not reflected to the binaries? I also tried to download source,
but seems like GIT is very tedious to configure.
On Jan 3, 8:47 pm, Siju Varghese varghese.s...@gmail.com wrote:
You could usehttps://github.com/sijuv/protobuf-codec. You can check the
test case
athttps://github.com/sijuv/protobuf-codec/blob/master/protobuf-codec-js...
usage. This library is listed under the google protobuf
ThirdPartyAddOns
wiki as Another JSON encoder/decoder for
Javahttps://github.com/sijuv/protobuf-codec.
Let me know if you run into any issues.
Regards.
On Wed, Dec 29, 2010 at 4:34 AM, Kenton Varda ken...@google.com wrote:
You should probably contact the authors of protobuf-java-format; I'm not
sure if they pay attention to this list.
Base64 is the best way to encode arbitrary (non-text) data as text.
However, it's really up to the JSON converter code you are using to decide
what format to use. As far as I know, JSON does not specify any particular
encoding for arbitrary bytes.
On Sat, Dec 25, 2010 at 2:40 AM, yalmasri y.alma...@gmail.com wrote:
Thanks for the reply.
I encoded Hello world in Base64 and I got this SGVsbG8gd29ybGQ=.
That doesn't look close to the format I sent in the question. Here's
the code snippet I used:
import org.apache.commons.codec.binary.Base64;
public class Codec {
public static void main(String[] args) {
try {
String clearText = Hello world;
// Base64
System.out.println(Encoded: +
Base64.encodeBase64String(clearText.getBytes()));
} catch (Exception e) {
e.printStackTrace();
}
}
}
I'm using this:http://code.google.com/p/protobuf-java-format/for
JSON -- PB conversion
On Dec 23, 3:48 am, Kenton Varda ken...@google.com wrote:
You will probably need to base64-encode bytes fields before embedding
them
in JSON, since JSON is a text format.
Which JSON - protobuf converter are you using? Or did you write your
own?
On Tue, Dec 21, 2010 at 11:41 PM, yalmasri y.alma...@gmail.com wrote:
Hello,
One of our customers is still using legacy Java 1.4 and therefore
could not use PB. For that we created an intermediate service that
receives text messages in plain JSON format then convert them into
generated PB objects.
In one object we have a field named desc of type bytes which will
hold a textual description of the arriving message. When the customer
wants to send English text for desc the value in JSON will be plain
readable English, but if non-ASCII is to be used, how the value in
JSON will look like? It look to me something like:
\0069\0062\006J\0062\006J\000 \006\'\006D\0069\006E\006J\006D\006\f
\000 \006D\006B\006/\000 \006\'\006F\006*\006G\006I\000
But I really don't know how to get this out of non-ASCII characters.
Can anyone help?
--
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 unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
protobuf%2bunsubscr...@googlegroups.comprotobuf%252bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
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 unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
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 unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
--
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 unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.
