[protobuf] Re: Issue 166 in protobuf: by_symbol_.insert(iter, make_pair(name, value)); fails with Sun Studio 12
Comment #2 on issue 166 by maciej.blizinski: by_symbol_.insert(iter, make_pair(name, value)); fails with Sun Studio 12 http://code.google.com/p/protobuf/issues/detail?id=166 I worked around the issue by using an alternative STL implementation. This page has something that might be a different workaround. http://developers.sun.com/solaris/articles/cmp_stlport_libCstd.html This issue might be a duplicate of issue 134. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- 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] Fudge proto project
Hi all, Have you seen this: http://www.fudgemsg.org/display/FDG/Fudge+Proto which claims to be compatible with the syntax of protobufs but use different on-disk and on-the-wire representations? -- 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] Fudge proto project
On Sun, Feb 28, 2010 at 09:13, Adewale Oshineye adew...@gmail.com wrote: Hi all, Have you seen this: http://www.fudgemsg.org/display/FDG/Fudge+Proto which claims to be compatible with the syntax of protobufs but use different on-disk and on-the-wire representations? Looks like they fell into the trap of wanting to provide self-description (with a pretty high overhead per message) and, worse, message inheritance. -h -- 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] strange encoding
I created (from tutorial example) below message. Person ID: 1 Name: Adam E-mail address: adam...@tlen.pl Home phone #: 12345 Mobile phone #: Person ID: 2 Name: Honorata E-mail address: hon...@wp.pl Work phone #: 4 Home phone #: 2 Person ID: 3 Name: Przemek E-mail address: przemek©...@tlen.pl Home phone #: 55 It was encoded as: 0A 2E 0A 04 41 64 61 6D 10 01 1A 0F 61 64 61 6D 64 6D 73 40 74 6C 65 6E 2E 70 6C 22 09 0A 05 31 32 33 34 35 10 01 22 08 0A 04 39 39 39 39 10 00 0A 30 0A 08 48 6F 6E 6F 72 61 74 61 10 02 1A 0C 68 6F 6E 63 69 6B 40 77 70 2E 70 6C 22 09 0A 05 34 34 34 34 34 10 02 22 09 0A 05 32 32 32 32 32 10 01 0A 2D 0A 07 50 72 7A 65 6D 65 6B 10 03 1A 14 70 72 7A 65 6D 65 6B C2 A9 63 6F 73 40 74 6C 65 6E 2E 70 6C 22 0A 0A 06 35 35 35 35 35 35 10 01 I don't understand that encoding! 0A - 0|000 1010 - wire type 0 (variant); field number 1 (but in .proto field Person ID has number 2) 2E - 0|010 1110 - 46 (but first person has ID = 1) 0A - 0|000 1010 - wire type 0 (variant, but that field is string, it should be type = 2); field number 1 (it is ok) 04 - length is ok 41 - A 64 - d 61 - a 6D - m ... Can someone explain this to me? -- 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] different results parsing from string in Java and Python
Hi, I'm having a problem reading messages produced in Java using Python. I'm using version 2.0.3 on a PowerPC Mac (OS X 10.4.11). I wrote a Java program that saves a series of messages to a file. Also using Java, I've succeeded in reading the messages back in from the file with the parseFrom() method. The problem arises when I try to read them in using Python. When I do this, using the ParseFromString() method, I get partially correct messages, but all the double fields are completely wrong, e.g., instead of the number 1.25 I get 3.08924426375e-319. Apart from the double fields, the messages are read in correctly. I'd be very grateful for any ideas about what could be going wrong here. 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] strange encoding
On Sun, Feb 28, 2010 at 3:47 AM, adamdms adam.kwintkiew...@gmail.comwrote:
I created (from tutorial example) below message.
Person ID: 1
Name: Adam
E-mail address: adam...@tlen.pl
Home phone #: 12345
Mobile phone #:
Person ID: 2
Name: Honorata
E-mail address: hon...@wp.pl
Work phone #: 4
Home phone #: 2
Person ID: 3
Name: Przemek
E-mail address: przemek©...@tlen.pl
Home phone #: 55
It was encoded as:
0A 2E 0A 04 41 64 61 6D 10 01 1A 0F 61 64 61 6D 64 6D 73 40 74 6C 65
6E 2E 70 6C 22 09 0A 05 31 32 33 34 35 10 01 22 08 0A 04 39 39 39 39
10 00 0A 30 0A 08 48 6F 6E 6F 72 61 74 61 10 02 1A 0C 68 6F 6E 63 69
6B 40 77 70 2E 70 6C 22 09 0A 05 34 34 34 34 34 10 02 22 09 0A 05 32
32 32 32 32 10 01 0A 2D 0A 07 50 72 7A 65 6D 65 6B 10 03 1A 14 70 72
7A 65 6D 65 6B C2 A9 63 6F 73 40 74 6C 65 6E 2E 70 6C 22 0A 0A 06 35
35 35 35 35 35 10 01
I don't understand that encoding!
0A - 0|000 1010 - wire type 0 (variant); field number 1 (but in .proto
field Person ID has number 2)
This is field number 1, wire type 2 (length-delimited).
Remember that the thing you are encoding is an AddressBook, not a Person.
message AddressBook {
repeated Person person = 1;
}
So the first byte is the tag for a person in the AddressBook.
2E - 0|010 1110 - 46 (but first person has ID = 1)
This is the length of the Person message.
0A - 0|000 1010 - wire type 0 (variant, but that field is string, it
should be type = 2); field number 1 (it is ok)
Now we're actually in the Person, so this is the name field. Note that
fields are ordered by field number, so name always comes *before* id.
04 - length is ok
41 - A
64 - d
61 - a
6D - m
...
Can someone explain this to me?
--
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.
