[protobuf] Problem with configure/make in protobuf
I am trying to compile/install protobuf. I have a solaris 10 and I read the README.txt and as per it, I did $ ./configure --prefix=PATH LDFLAGS=-L$PWD/src/solaris it was still reading libstdc++.la from /usr/sfw/lib Then I set it to as per the comments I saw in src/solaris/libstdc++.la as follows. $ ./configure --prefix=PATH LDFLAGS='-Lsrc/solaris' When I do $make I get this error. ../libtool: line 4463: cd: src/solaris: No such file or directory libtool: link: cannot determine absolute directory name of `src/ solaris' Any ideas how to fix this? -Prasad. -- 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] Creating an instance of a message from the descriptor (java)
Hi,
I'm having trouble getting the following code to work. Using
protoc.exe, I generated a file with the descriptor data using the --
descriptor_set_out file. I've written some Java code to read the
file, and try to instantiate a default instance of one of the objects
in the descriptor, so that I write it out to an XML file using the
protobuf-format-java library.
Here's my code. The variable descriptorData contains the binary
content of the descriptor file, without any modifications:
DescriptorProtos.FileDescriptorSet fdSet =
FileDescriptorSet.newBuilder().mergeFrom(descriptorData).build();
FileDescriptorProto fdp = fdSet.getFile(0);
ListDescriptorProto messageTypes = fdp.getMessageTypeList();
for(DescriptorProto type : messageTypes)
{
System.out.println(Type is: + type.getName());
FileDescriptor fd =
type.getDescriptorForType().getFile();
DynamicMessage dm =
DynamicMessage.getDefaultInstance(type.getDescriptorForType());
System.out.println(XmlFormat.printToString(dm));
}
I've tried numerous combinations of the above code, but each time I
get the following output:
Type is: Type1
DescriptorProto/DescriptorProto
Type is: Type2
DescriptorProto/DescriptorProto
Type is: Type3
DescriptorProto/DescriptorProto
Type is: Type4
DescriptorProto/DescriptorProto
Type is: Type5
DescriptorProto/DescriptorProto
Type is: Type6
DescriptorProto/DescriptorProto
The proto file has Type1, Type2, Type3, etc, defined as messages. The
fact that type.getName() does return the type names from my proto
file, leads me to believe I'm heading in the right direction.
However, the DynamicMessage type that is created (and serialized to
XML) seems to indicate that I'm not passing the right descriptor
instance in to create the object.
Any thoughts?
Thanks,
Kevin
--
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] Problem with configure/make in protobuf
On Sat, Mar 20, 2010 at 2:37 PM, Prasad prasadsri...@gmail.com wrote: I am trying to compile/install protobuf. I have a solaris 10 and I read the README.txt and as per it, I did $ ./configure --prefix=PATH LDFLAGS=-L$PWD/src/solaris it was still reading libstdc++.la from /usr/sfw/lib Then I set it to as per the comments I saw in src/solaris/libstdc++.la as follows. $ ./configure --prefix=PATH LDFLAGS='-Lsrc/solaris' Most compilation happens in src/Makefile, so you'd just want -Lsolaris there. So I think your first approach (using the full path) was best. Beyond that I don't know. I haven't used solaris myself. When I do $make I get this error. ../libtool: line 4463: cd: src/solaris: No such file or directory libtool: link: cannot determine absolute directory name of `src/ solaris' Any ideas how to fix this? -Prasad. -- 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] Best method for adding to messages..
Hi all,
I'm trying to write a protobuf to detect the RSSI values of some
wireless stations in the area. I'm having some trouble 'updating' the
RSSI value of a station if it has already been seen before. At the
minute I'm doing a strcmp of the Station MAC from the message and the
MAC retrieved from libpcap, and then if they match attempting to
add_rssi(rssi_val) to that station.
My questions are -
1) is there a better method of searching through the stations already
entered in the message.
2) what's the best method for updating the rssi of an indexed station?
i'm using the following method at the minute, but it is not working as
can't add_rssi to a const:
// if station has been seen before
for(int k = 0; k stationlog.station_size(); k++) {
const DIDS::Station station_iter = stationlog.station(k);
if (strcmp(station_iter.mac().c_str(), libpcapSta-mac-
unparse().c_str()) == 0) {
station_iter.add_rssi(libpcapSta-rssi);
}
}
the .proto file i'm using is:
--
package DIDS;
message Station {
optional string mac = 2;
optional int32 beacons = 3;
repeated int32 rssi = 4;
}
message Instance {
repeated Station station = 1;
}
--
Thanks, and apologies if I've missed something obvious!
--
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] File size of the serialized records
I was testing to see the upper limit for numbers of records in one file. I used the addressbook example, and I noticed that for one record it generates file double the size. for ex. size of the class I was putting into it was 48 bytes and the file was of 97 bytes on ubuntu 9.10. Now, I go test it with 1000 records bang! it goes many fold and with records in hundreds of thousands, file size increases in many folds. Has anyone investigated around this area ? I did not note down the exact numbers as I thought someone should already have done it. Please let me know if you want the detail test numbers, I can run through it again and provide you with information. -- 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] Best method for adding to messages..
On Mar 22, 2010, at 14:00 , Olan wrote: const DIDS::Station station_iter = stationlog.station(k); You probably want stationlog.mutable_station(k); See: http://code.google.com/apis/protocolbuffers/docs/reference/cpp-generated.html#fields Hope this helps, Evan -- Evan Jones http://evanjones.ca/ -- 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] File size of the serialized records
If you're measuring using sizeof(), you won't account for memory allocated by subobjects (strings and submessages are stored as pointers). You should use Message::SpaceUsed() instead. The inmemory vs serialized size is going to depend on your proto definition and how you use it. If you have a lot of optional fields, but only set one of them, the serialized size will likely be much smaller than the in memory size. If you have lots of large strings, they're probably going to be pretty close since both sizes will be dominated by the actual bytes of the strings. It sounds like you are surprised that the serialized size increases as you increase the number of records. What exactly do you expect to happen here? On Mon, Mar 22, 2010 at 12:15 PM, Vinit shortempe...@gmail.com wrote: I was testing to see the upper limit for numbers of records in one file. I used the addressbook example, and I noticed that for one record it generates file double the size. for ex. size of the class I was putting into it was 48 bytes and the file was of 97 bytes on ubuntu 9.10. Now, I go test it with 1000 records bang! it goes many fold and with records in hundreds of thousands, file size increases in many folds. Has anyone investigated around this area ? I did not note down the exact numbers as I thought someone should already have done it. Please let me know if you want the detail test numbers, I can run through it again and provide you with information. -- 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] Creating an instance of a message from the descriptor (java)
DescriptorProto.getDescriptorForType() returns the Descriptor for
DescriptorProto, not for the type which that DescriptorProto is describing.
Remember that DescriptorProto is just a protocol message like any other --
it does not have any special methods that recognize its higher-level
meaning.
To convert DescriptorProtos to Descriptors, you need to use
FileDescriptor.buildFrom().
On Sun, Mar 21, 2010 at 5:20 PM, Kevin Tambascio
kevin.tambas...@gmail.comwrote:
Hi,
I'm having trouble getting the following code to work. Using
protoc.exe, I generated a file with the descriptor data using the --
descriptor_set_out file. I've written some Java code to read the
file, and try to instantiate a default instance of one of the objects
in the descriptor, so that I write it out to an XML file using the
protobuf-format-java library.
Here's my code. The variable descriptorData contains the binary
content of the descriptor file, without any modifications:
DescriptorProtos.FileDescriptorSet fdSet =
FileDescriptorSet.newBuilder().mergeFrom(descriptorData).build();
FileDescriptorProto fdp = fdSet.getFile(0);
ListDescriptorProto messageTypes =
fdp.getMessageTypeList();
for(DescriptorProto type : messageTypes)
{
System.out.println(Type is: + type.getName());
FileDescriptor fd =
type.getDescriptorForType().getFile();
DynamicMessage dm =
DynamicMessage.getDefaultInstance(type.getDescriptorForType());
System.out.println(XmlFormat.printToString(dm));
}
I've tried numerous combinations of the above code, but each time I
get the following output:
Type is: Type1
DescriptorProto/DescriptorProto
Type is: Type2
DescriptorProto/DescriptorProto
Type is: Type3
DescriptorProto/DescriptorProto
Type is: Type4
DescriptorProto/DescriptorProto
Type is: Type5
DescriptorProto/DescriptorProto
Type is: Type6
DescriptorProto/DescriptorProto
The proto file has Type1, Type2, Type3, etc, defined as messages. The
fact that type.getName() does return the type names from my proto
file, leads me to believe I'm heading in the right direction.
However, the DynamicMessage type that is created (and serialized to
XML) seems to indicate that I'm not passing the right descriptor
instance in to create the object.
Any thoughts?
Thanks,
Kevin
--
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] File size of the serialized records
Hi Jason, Thanks for the quick reply. I am not surprised by the increase in file size, But I am under impression that If I insert the same record thousand times, the size of file should be large accordingly, e.g, assume that one record generates the file of size 32 bytes; with1024 records should sum up to 32K size or close to that but it does not and that is why I am surprised. The growth in size is not linear and that was the reason I posted my findings. I am a student so might be missing a small concept or anything here, if so, apologies in advance for taking your time. Once again appreciate your help, On Mon, Mar 22, 2010 at 12:42 PM, Jason Hsueh jas...@google.com wrote: If you're measuring using sizeof(), you won't account for memory allocated by subobjects (strings and submessages are stored as pointers). You should use Message::SpaceUsed() instead. The inmemory vs serialized size is going to depend on your proto definition and how you use it. If you have a lot of optional fields, but only set one of them, the serialized size will likely be much smaller than the in memory size. If you have lots of large strings, they're probably going to be pretty close since both sizes will be dominated by the actual bytes of the strings. It sounds like you are surprised that the serialized size increases as you increase the number of records. What exactly do you expect to happen here? On Mon, Mar 22, 2010 at 12:15 PM, Vinit shortempe...@gmail.com wrote: I was testing to see the upper limit for numbers of records in one file. I used the addressbook example, and I noticed that for one record it generates file double the size. for ex. size of the class I was putting into it was 48 bytes and the file was of 97 bytes on ubuntu 9.10. Now, I go test it with 1000 records bang! it goes many fold and with records in hundreds of thousands, file size increases in many folds. Has anyone investigated around this area ? I did not note down the exact numbers as I thought someone should already have done it. Please let me know if you want the detail test numbers, I can run through it again and provide you with information. -- 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. -- Vinit -- 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] File size of the serialized records
The most likely cause is a bug in your code where there's something you aren't clearing each time you write a record, so at each iteration in your loop, the record you're writing is getting bigger. Of course I can't say for sure without seeing the code. Daniel On Mon, Mar 22, 2010 at 1:13 PM, Vinit Mahedia shortempe...@gmail.comwrote: Hi Jason, Thanks for the quick reply. I am not surprised by the increase in file size, But I am under impression that If I insert the same record thousand times, the size of file should be large accordingly, e.g, assume that one record generates the file of size 32 bytes; with1024 records should sum up to 32K size or close to that but it does not and that is why I am surprised. The growth in size is not linear and that was the reason I posted my findings. I am a student so might be missing a small concept or anything here, if so, apologies in advance for taking your time. Once again appreciate your help, On Mon, Mar 22, 2010 at 12:42 PM, Jason Hsueh jas...@google.com wrote: If you're measuring using sizeof(), you won't account for memory allocated by subobjects (strings and submessages are stored as pointers). You should use Message::SpaceUsed() instead. The inmemory vs serialized size is going to depend on your proto definition and how you use it. If you have a lot of optional fields, but only set one of them, the serialized size will likely be much smaller than the in memory size. If you have lots of large strings, they're probably going to be pretty close since both sizes will be dominated by the actual bytes of the strings. It sounds like you are surprised that the serialized size increases as you increase the number of records. What exactly do you expect to happen here? On Mon, Mar 22, 2010 at 12:15 PM, Vinit shortempe...@gmail.com wrote: I was testing to see the upper limit for numbers of records in one file. I used the addressbook example, and I noticed that for one record it generates file double the size. for ex. size of the class I was putting into it was 48 bytes and the file was of 97 bytes on ubuntu 9.10. Now, I go test it with 1000 records bang! it goes many fold and with records in hundreds of thousands, file size increases in many folds. Has anyone investigated around this area ? I did not note down the exact numbers as I thought someone should already have done it. Please let me know if you want the detail test numbers, I can run through it again and provide you with information. -- 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. -- Vinit -- 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] File size of the serialized records
I am using add_person.cc provided in the sample file. The only change I have
done is,
a while loop around this code. So it's same record inserted multiple times.
// Write the new address book back to disk.fstream output(argv[1], ios::out
| ios::trunc | ios::binary);
*int nRecords = 10;*
*while ( nRecords-- )*
*{*if (!address_book.SerializeToOstream(output)) {
cerr Failed to write address book. endl;
return -1;
}*}*
On Mon, Mar 22, 2010 at 1:34 PM, Daniel Wright dwri...@google.com wrote:
The most likely cause is a bug in your code where there's something you
aren't clearing each time you write a record, so at each iteration in your
loop, the record you're writing is getting bigger. Of course I can't say
for sure without seeing the code.
Daniel
On Mon, Mar 22, 2010 at 1:13 PM, Vinit Mahedia shortempe...@gmail.comwrote:
Hi Jason,
Thanks for the quick reply.
I am not surprised by the increase in file size, But I am under impression
that If I insert the same record
thousand times, the size of file should be large accordingly,
e.g, assume that one record generates the file of size 32 bytes; with1024
records should sum up to 32K
size or close to that but it does not and that is why I am surprised. The
growth in size is not linear and
that was the reason I posted my findings. I am a student so might be
missing a small concept or anything
here, if so, apologies in advance for taking your time.
Once again appreciate your help,
On Mon, Mar 22, 2010 at 12:42 PM, Jason Hsueh jas...@google.com wrote:
If you're measuring using sizeof(), you won't account for memory
allocated by subobjects (strings and submessages are stored as pointers).
You should use Message::SpaceUsed() instead. The inmemory vs serialized size
is going to depend on your proto definition and how you use it. If you have
a lot of optional fields, but only set one of them, the serialized size will
likely be much smaller than the in memory size. If you have lots of large
strings, they're probably going to be pretty close since both sizes will be
dominated by the actual bytes of the strings.
It sounds like you are surprised that the serialized size increases as
you increase the number of records. What exactly do you expect to happen
here?
On Mon, Mar 22, 2010 at 12:15 PM, Vinit shortempe...@gmail.com wrote:
I was testing to see the upper limit for numbers of records in one
file.
I used the addressbook example, and I noticed that for one record
it generates file double the size.
for ex. size of the class I was putting into it was 48 bytes and the
file
was of 97 bytes on ubuntu 9.10.
Now, I go test it with 1000 records bang! it goes many fold and with
records in hundreds of thousands, file size increases in many folds.
Has anyone investigated around this area ? I did not note down the
exact numbers as I thought someone should already have done it.
Please let me know if you want the detail test numbers, I can run
through it again and provide you with information.
--
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.
--
Vinit
--
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.
--
Vinit
--
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] File size of the serialized records
That's not the right way to write multiple records. What you're doing is
writing multiple address books without proper boundaries between them. The
right thing to do would be to add multiple persons to one address book,
then write it once.
That said, the file produced by your code should grow proportionally to
nRecords, since you're just writing the exact same bytes nRecords times. So
there must be some other problem in some part of your code which you didn't
show us.
On Mon, Mar 22, 2010 at 1:56 PM, Vinit Mahedia shortempe...@gmail.comwrote:
I am using add_person.cc provided in the sample file. The only change I
have done is,
a while loop around this code. So it's same record inserted multiple times.
// Write the new address book back to disk. fstream output(argv[1], ios::out
| ios::trunc | ios::binary);
*int nRecords = 10;*
*while ( nRecords-- )*
*{* if (!address_book.SerializeToOstream(output)) {
cerr Failed to write address book. endl;
return -1;
}
*}*
On Mon, Mar 22, 2010 at 1:34 PM, Daniel Wright dwri...@google.com wrote:
The most likely cause is a bug in your code where there's something you
aren't clearing each time you write a record, so at each iteration in your
loop, the record you're writing is getting bigger. Of course I can't say
for sure without seeing the code.
Daniel
On Mon, Mar 22, 2010 at 1:13 PM, Vinit Mahedia shortempe...@gmail.comwrote:
Hi Jason,
Thanks for the quick reply.
I am not surprised by the increase in file size, But I am under
impression that If I insert the same record
thousand times, the size of file should be large accordingly,
e.g, assume that one record generates the file of size 32 bytes; with1024
records should sum up to 32K
size or close to that but it does not and that is why I am surprised. The
growth in size is not linear and
that was the reason I posted my findings. I am a student so might be
missing a small concept or anything
here, if so, apologies in advance for taking your time.
Once again appreciate your help,
On Mon, Mar 22, 2010 at 12:42 PM, Jason Hsueh jas...@google.com wrote:
If you're measuring using sizeof(), you won't account for memory
allocated by subobjects (strings and submessages are stored as pointers).
You should use Message::SpaceUsed() instead. The inmemory vs serialized
size
is going to depend on your proto definition and how you use it. If you have
a lot of optional fields, but only set one of them, the serialized size
will
likely be much smaller than the in memory size. If you have lots of large
strings, they're probably going to be pretty close since both sizes will be
dominated by the actual bytes of the strings.
It sounds like you are surprised that the serialized size increases as
you increase the number of records. What exactly do you expect to happen
here?
On Mon, Mar 22, 2010 at 12:15 PM, Vinit shortempe...@gmail.com wrote:
I was testing to see the upper limit for numbers of records in one
file.
I used the addressbook example, and I noticed that for one record
it generates file double the size.
for ex. size of the class I was putting into it was 48 bytes and the
file
was of 97 bytes on ubuntu 9.10.
Now, I go test it with 1000 records bang! it goes many fold and with
records in hundreds of thousands, file size increases in many folds.
Has anyone investigated around this area ? I did not note down the
exact numbers as I thought someone should already have done it.
Please let me know if you want the detail test numbers, I can run
through it again and provide you with information.
--
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.
--
Vinit
--
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.
--
Vinit
--
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
[protobuf] Re: Creating an instance of a message from the descriptor (java)
Kenton,
I did make some more progress today, along the lines of what you said
below. I'm seeing an issue where calling
DynamicMessage.getDefaultInstance(type) is not filling in the default
values. This is with 2.3.0 of GPB.
My proto file:
message StringTableEntry
{
required string lang = 1 [default = en-US];
required string value = 2 [default = ];
}
When I instantiate an instance of StringTableEntry, using
DynamicMessage, the required fields are not in the message instance.
From reading the documentation, it sounds like the default values
should show up if I create an object. My code for creation is this:
FileDescriptor fd =
FileDescriptor.buildFrom(fdSet.getFile(0), fds);
ListDescriptor messageTypes = fd.getMessageTypes();
for(Descriptor type : messageTypes)
{
DynamicMessage dm =
DynamicMessage.newBuilder(type).getDefaultInstanceForType();
//DynamicMessage dm =
DynamicMessage.getDefaultInstance(type);
MapFieldDescriptor, Object dmFields =
dm.getAllFields();
for(EntryFieldDescriptor, Object entry :
dmFields.entrySet())
{
System.out.println(default value for this
field: +
entry.getValue().toString());
entry.setValue(Data);
}
System.out.println(XmlFormat.printToString(dm));
}
When instantiating the object, using either the commented or
uncommented out lines of code above, fails to contain the required
fields with their default values. If I poke around the 'type'
variable in the debugger, I can see that the 2 fields are in the
descriptor, and the default values are there as well. But the
instance of the message does not contain those two fields
(dmFields.entrySet() returns null, and the code inside the
for(EntryFieldDescriptor, Object entry : dmFields.entrySet()) loop
does not execute).
It seems like I could write a routine to set the default values based
on the Descriptor data, but I think that getDefaultInstance should do
that for me.
Thoughts?
Thanks,
Kevin
On Mar 22, 4:02 pm, Kenton Varda ken...@google.com wrote:
DescriptorProto.getDescriptorForType() returns the Descriptor for
DescriptorProto, not for the type which that DescriptorProto is describing.
Remember that DescriptorProto is just a protocol message like any other --
it does not have any special methods that recognize its higher-level
meaning.
To convert DescriptorProtos to Descriptors, you need to use
FileDescriptor.buildFrom().
On Sun, Mar 21, 2010 at 5:20 PM, Kevin Tambascio
kevin.tambas...@gmail.comwrote:
Hi,
I'm having trouble getting the following code to work. Using
protoc.exe, I generated a file with the descriptor data using the --
descriptor_set_out file. I've written some Java code to read the
file, and try to instantiate a default instance of one of the objects
in the descriptor, so that I write it out to an XML file using the
protobuf-format-java library.
Here's my code. The variable descriptorData contains the binary
content of the descriptor file, without any modifications:
DescriptorProtos.FileDescriptorSet fdSet =
FileDescriptorSet.newBuilder().mergeFrom(descriptorData).build();
FileDescriptorProto fdp = fdSet.getFile(0);
ListDescriptorProto messageTypes =
fdp.getMessageTypeList();
for(DescriptorProto type : messageTypes)
{
System.out.println(Type is: + type.getName());
FileDescriptor fd =
type.getDescriptorForType().getFile();
DynamicMessage dm =
DynamicMessage.getDefaultInstance(type.getDescriptorForType());
System.out.println(XmlFormat.printToString(dm));
}
I've tried numerous combinations of the above code, but each time I
get the following output:
Type is: Type1
DescriptorProto/DescriptorProto
Type is: Type2
DescriptorProto/DescriptorProto
Type is: Type3
DescriptorProto/DescriptorProto
Type is: Type4
DescriptorProto/DescriptorProto
Type is: Type5
DescriptorProto/DescriptorProto
Type is: Type6
DescriptorProto/DescriptorProto
The proto file has Type1, Type2, Type3, etc, defined as messages. The
fact that type.getName() does return the type names from my proto
file, leads me to believe I'm heading in the right direction.
However, the DynamicMessage type that is created (and serialized to
XML) seems to indicate that I'm not passing the right descriptor
instance in to create the object.
Any thoughts?
Thanks,
Kevin
--
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
Re: [protobuf] Re: Creating an instance of a message from the descriptor (java)
required means If this field is not explicitly set before build() is
called, or if parseFrom() parses a message missing this field, throw an
exception.. It does NOT mean Automatically fill in this field.. Please
point me at any documentation which suggests the latter meaning so I can fix
it.
The default value is the value returned by the field's getter when the field
has not been explicitly assigned any other value.
getAllFields() only returns field which have been explicitly set.
On Mon, Mar 22, 2010 at 2:42 PM, Kevin Tambascio
kevin.tambas...@gmail.comwrote:
Kenton,
I did make some more progress today, along the lines of what you said
below. I'm seeing an issue where calling
DynamicMessage.getDefaultInstance(type) is not filling in the default
values. This is with 2.3.0 of GPB.
My proto file:
message StringTableEntry
{
required string lang = 1 [default = en-US];
required string value = 2 [default = ];
}
When I instantiate an instance of StringTableEntry, using
DynamicMessage, the required fields are not in the message instance.
From reading the documentation, it sounds like the default values
should show up if I create an object. My code for creation is this:
FileDescriptor fd =
FileDescriptor.buildFrom(fdSet.getFile(0), fds);
ListDescriptor messageTypes = fd.getMessageTypes();
for(Descriptor type : messageTypes)
{
DynamicMessage dm =
DynamicMessage.newBuilder(type).getDefaultInstanceForType();
//DynamicMessage dm =
DynamicMessage.getDefaultInstance(type);
MapFieldDescriptor, Object dmFields =
dm.getAllFields();
for(EntryFieldDescriptor, Object entry :
dmFields.entrySet())
{
System.out.println(default value for this
field: +
entry.getValue().toString());
entry.setValue(Data);
}
System.out.println(XmlFormat.printToString(dm));
}
When instantiating the object, using either the commented or
uncommented out lines of code above, fails to contain the required
fields with their default values. If I poke around the 'type'
variable in the debugger, I can see that the 2 fields are in the
descriptor, and the default values are there as well. But the
instance of the message does not contain those two fields
(dmFields.entrySet() returns null, and the code inside the
for(EntryFieldDescriptor, Object entry : dmFields.entrySet()) loop
does not execute).
It seems like I could write a routine to set the default values based
on the Descriptor data, but I think that getDefaultInstance should do
that for me.
Thoughts?
Thanks,
Kevin
On Mar 22, 4:02 pm, Kenton Varda ken...@google.com wrote:
DescriptorProto.getDescriptorForType() returns the Descriptor for
DescriptorProto, not for the type which that DescriptorProto is
describing.
Remember that DescriptorProto is just a protocol message like any other
--
it does not have any special methods that recognize its higher-level
meaning.
To convert DescriptorProtos to Descriptors, you need to use
FileDescriptor.buildFrom().
On Sun, Mar 21, 2010 at 5:20 PM, Kevin Tambascio
kevin.tambas...@gmail.comwrote:
Hi,
I'm having trouble getting the following code to work. Using
protoc.exe, I generated a file with the descriptor data using the --
descriptor_set_out file. I've written some Java code to read the
file, and try to instantiate a default instance of one of the objects
in the descriptor, so that I write it out to an XML file using the
protobuf-format-java library.
Here's my code. The variable descriptorData contains the binary
content of the descriptor file, without any modifications:
DescriptorProtos.FileDescriptorSet fdSet =
FileDescriptorSet.newBuilder().mergeFrom(descriptorData).build();
FileDescriptorProto fdp = fdSet.getFile(0);
ListDescriptorProto messageTypes =
fdp.getMessageTypeList();
for(DescriptorProto type : messageTypes)
{
System.out.println(Type is: +
type.getName());
FileDescriptor fd =
type.getDescriptorForType().getFile();
DynamicMessage dm =
DynamicMessage.getDefaultInstance(type.getDescriptorForType());
System.out.println(XmlFormat.printToString(dm));
}
I've tried numerous combinations of the above code, but each time I
get the following output:
Type is: Type1
DescriptorProto/DescriptorProto
Type is: Type2
DescriptorProto/DescriptorProto
Type is: Type3
DescriptorProto/DescriptorProto
Type is: Type4
DescriptorProto/DescriptorProto
Type is: Type5
[protobuf] Re: Issue 174 in protobuf: RFE: Allow service defs in optimize_for=LITE_RUNTIME if *_generic_service = false
Updates: Status: Accepted Comment #1 on issue 174 by ken...@google.com: RFE: Allow service defs in optimize_for=LITE_RUNTIME if *_generic_service = false http://code.google.com/p/protobuf/issues/detail?id=174 Yep, this is an artifact of lite mode having been implemented before plugins were invented, and then the two never being tested together... -- 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] Re: Creating an instance of a message from the descriptor (java)
Kenton,
This description in the MessageLite documentation is what led me to
believe the default values would be there. I figured I was
misinterpreting the documentation, or the meaning behind the default
value:
getDefaultInstanceForType
MessageLite getDefaultInstanceForType()
Get an instance of the type with all fields set to their default
values. This may or may not be a singleton. This differs from the
getDefaultInstance() method of generated message classes in that this
method is an abstract method of the MessageLite interface whereas
getDefaultInstance() is a static method of a specific class. They
return the same thing.
http://code.google.com/apis/protocolbuffers/docs/reference/java/index.html
Thanks for your help,
Kevin
On Mar 22, 7:07 pm, Kenton Varda ken...@google.com wrote:
required means If this field is not explicitly set before build() is
called, or if parseFrom() parses a message missing this field, throw an
exception.. It does NOT mean Automatically fill in this field.. Please
point me at any documentation which suggests the latter meaning so I can fix
it.
The default value is the value returned by the field's getter when the field
has not been explicitly assigned any other value.
getAllFields() only returns field which have been explicitly set.
On Mon, Mar 22, 2010 at 2:42 PM, Kevin Tambascio
kevin.tambas...@gmail.comwrote:
Kenton,
I did make some more progress today, along the lines of what you said
below. I'm seeing an issue where calling
DynamicMessage.getDefaultInstance(type) is not filling in the default
values. This is with 2.3.0 of GPB.
My proto file:
message StringTableEntry
{
required string lang = 1 [default = en-US];
required string value = 2 [default = ];
}
When I instantiate an instance of StringTableEntry, using
DynamicMessage, the required fields are not in the message instance.
From reading the documentation, it sounds like the default values
should show up if I create an object. My code for creation is this:
FileDescriptor fd =
FileDescriptor.buildFrom(fdSet.getFile(0), fds);
ListDescriptor messageTypes = fd.getMessageTypes();
for(Descriptor type : messageTypes)
{
DynamicMessage dm =
DynamicMessage.newBuilder(type).getDefaultInstanceForType();
//DynamicMessage dm =
DynamicMessage.getDefaultInstance(type);
MapFieldDescriptor, Object dmFields =
dm.getAllFields();
for(EntryFieldDescriptor, Object entry :
dmFields.entrySet())
{
System.out.println(default value for this
field: +
entry.getValue().toString());
entry.setValue(Data);
}
System.out.println(XmlFormat.printToString(dm));
}
When instantiating the object, using either the commented or
uncommented out lines of code above, fails to contain the required
fields with their default values. If I poke around the 'type'
variable in the debugger, I can see that the 2 fields are in the
descriptor, and the default values are there as well. But the
instance of the message does not contain those two fields
(dmFields.entrySet() returns null, and the code inside the
for(EntryFieldDescriptor, Object entry : dmFields.entrySet()) loop
does not execute).
It seems like I could write a routine to set the default values based
on the Descriptor data, but I think that getDefaultInstance should do
that for me.
Thoughts?
Thanks,
Kevin
On Mar 22, 4:02 pm, Kenton Varda ken...@google.com wrote:
DescriptorProto.getDescriptorForType() returns the Descriptor for
DescriptorProto, not for the type which that DescriptorProto is
describing.
Remember that DescriptorProto is just a protocol message like any other
--
it does not have any special methods that recognize its higher-level
meaning.
To convert DescriptorProtos to Descriptors, you need to use
FileDescriptor.buildFrom().
On Sun, Mar 21, 2010 at 5:20 PM, Kevin Tambascio
kevin.tambas...@gmail.comwrote:
Hi,
I'm having trouble getting the following code to work. Using
protoc.exe, I generated a file with the descriptor data using the --
descriptor_set_out file. I've written some Java code to read the
file, and try to instantiate a default instance of one of the objects
in the descriptor, so that I write it out to an XML file using the
protobuf-format-java library.
Here's my code. The variable descriptorData contains the binary
content of the descriptor file, without any modifications:
DescriptorProtos.FileDescriptorSet fdSet =
FileDescriptorSet.newBuilder().mergeFrom(descriptorData).build();
FileDescriptorProto fdp = fdSet.getFile(0);
Re: [protobuf] Re: Creating an instance of a message from the descriptor (java)
Yeah, I can see how that is misleading (though it does not mention
required fields -- it claims all fields). It should say Get an instance
of the type with no fields set. Because no fields are set, all getters for
singular fields will return default values and repeated fields will appear
empty..
On Mon, Mar 22, 2010 at 4:56 PM, Kevin Tambascio
kevin.tambas...@gmail.comwrote:
Kenton,
This description in the MessageLite documentation is what led me to
believe the default values would be there. I figured I was
misinterpreting the documentation, or the meaning behind the default
value:
getDefaultInstanceForType
MessageLite getDefaultInstanceForType()
Get an instance of the type with all fields set to their default
values. This may or may not be a singleton. This differs from the
getDefaultInstance() method of generated message classes in that this
method is an abstract method of the MessageLite interface whereas
getDefaultInstance() is a static method of a specific class. They
return the same thing.
http://code.google.com/apis/protocolbuffers/docs/reference/java/index.html
Thanks for your help,
Kevin
On Mar 22, 7:07 pm, Kenton Varda ken...@google.com wrote:
required means If this field is not explicitly set before build() is
called, or if parseFrom() parses a message missing this field, throw an
exception.. It does NOT mean Automatically fill in this field..
Please
point me at any documentation which suggests the latter meaning so I can
fix
it.
The default value is the value returned by the field's getter when the
field
has not been explicitly assigned any other value.
getAllFields() only returns field which have been explicitly set.
On Mon, Mar 22, 2010 at 2:42 PM, Kevin Tambascio
kevin.tambas...@gmail.comwrote:
Kenton,
I did make some more progress today, along the lines of what you said
below. I'm seeing an issue where calling
DynamicMessage.getDefaultInstance(type) is not filling in the default
values. This is with 2.3.0 of GPB.
My proto file:
message StringTableEntry
{
required string lang = 1 [default = en-US];
required string value = 2 [default = ];
}
When I instantiate an instance of StringTableEntry, using
DynamicMessage, the required fields are not in the message instance.
From reading the documentation, it sounds like the default values
should show up if I create an object. My code for creation is this:
FileDescriptor fd =
FileDescriptor.buildFrom(fdSet.getFile(0), fds);
ListDescriptor messageTypes = fd.getMessageTypes();
for(Descriptor type : messageTypes)
{
DynamicMessage dm =
DynamicMessage.newBuilder(type).getDefaultInstanceForType();
//DynamicMessage dm =
DynamicMessage.getDefaultInstance(type);
MapFieldDescriptor, Object dmFields =
dm.getAllFields();
for(EntryFieldDescriptor, Object entry :
dmFields.entrySet())
{
System.out.println(default value for
this
field: +
entry.getValue().toString());
entry.setValue(Data);
}
System.out.println(XmlFormat.printToString(dm));
}
When instantiating the object, using either the commented or
uncommented out lines of code above, fails to contain the required
fields with their default values. If I poke around the 'type'
variable in the debugger, I can see that the 2 fields are in the
descriptor, and the default values are there as well. But the
instance of the message does not contain those two fields
(dmFields.entrySet() returns null, and the code inside the
for(EntryFieldDescriptor, Object entry : dmFields.entrySet()) loop
does not execute).
It seems like I could write a routine to set the default values based
on the Descriptor data, but I think that getDefaultInstance should do
that for me.
Thoughts?
Thanks,
Kevin
On Mar 22, 4:02 pm, Kenton Varda ken...@google.com wrote:
DescriptorProto.getDescriptorForType() returns the Descriptor for
DescriptorProto, not for the type which that DescriptorProto is
describing.
Remember that DescriptorProto is just a protocol message like any
other
--
it does not have any special methods that recognize its higher-level
meaning.
To convert DescriptorProtos to Descriptors, you need to use
FileDescriptor.buildFrom().
On Sun, Mar 21, 2010 at 5:20 PM, Kevin Tambascio
kevin.tambas...@gmail.comwrote:
Hi,
I'm having trouble getting the following code to work. Using
protoc.exe, I generated a file with the descriptor data using the
--
descriptor_set_out file. I've written some Java code to read the
file, and
Re: [protobuf] Re: Creating an instance of a message from the descriptor (java)
http://code.google.com/p/protobuf/issues/detail?id=175
On Mon, Mar 22, 2010 at 4:59 PM, Kenton Varda ken...@google.com wrote:
Yeah, I can see how that is misleading (though it does not mention
required fields -- it claims all fields). It should say Get an instance
of the type with no fields set. Because no fields are set, all getters for
singular fields will return default values and repeated fields will appear
empty..
On Mon, Mar 22, 2010 at 4:56 PM, Kevin Tambascio
kevin.tambas...@gmail.com wrote:
Kenton,
This description in the MessageLite documentation is what led me to
believe the default values would be there. I figured I was
misinterpreting the documentation, or the meaning behind the default
value:
getDefaultInstanceForType
MessageLite getDefaultInstanceForType()
Get an instance of the type with all fields set to their default
values. This may or may not be a singleton. This differs from the
getDefaultInstance() method of generated message classes in that this
method is an abstract method of the MessageLite interface whereas
getDefaultInstance() is a static method of a specific class. They
return the same thing.
http://code.google.com/apis/protocolbuffers/docs/reference/java/index.html
Thanks for your help,
Kevin
On Mar 22, 7:07 pm, Kenton Varda ken...@google.com wrote:
required means If this field is not explicitly set before build() is
called, or if parseFrom() parses a message missing this field, throw an
exception.. It does NOT mean Automatically fill in this field..
Please
point me at any documentation which suggests the latter meaning so I can
fix
it.
The default value is the value returned by the field's getter when the
field
has not been explicitly assigned any other value.
getAllFields() only returns field which have been explicitly set.
On Mon, Mar 22, 2010 at 2:42 PM, Kevin Tambascio
kevin.tambas...@gmail.comwrote:
Kenton,
I did make some more progress today, along the lines of what you said
below. I'm seeing an issue where calling
DynamicMessage.getDefaultInstance(type) is not filling in the default
values. This is with 2.3.0 of GPB.
My proto file:
message StringTableEntry
{
required string lang = 1 [default = en-US];
required string value = 2 [default = ];
}
When I instantiate an instance of StringTableEntry, using
DynamicMessage, the required fields are not in the message instance.
From reading the documentation, it sounds like the default values
should show up if I create an object. My code for creation is this:
FileDescriptor fd =
FileDescriptor.buildFrom(fdSet.getFile(0), fds);
ListDescriptor messageTypes = fd.getMessageTypes();
for(Descriptor type : messageTypes)
{
DynamicMessage dm =
DynamicMessage.newBuilder(type).getDefaultInstanceForType();
//DynamicMessage dm =
DynamicMessage.getDefaultInstance(type);
MapFieldDescriptor, Object dmFields =
dm.getAllFields();
for(EntryFieldDescriptor, Object entry :
dmFields.entrySet())
{
System.out.println(default value for
this
field: +
entry.getValue().toString());
entry.setValue(Data);
}
System.out.println(XmlFormat.printToString(dm));
}
When instantiating the object, using either the commented or
uncommented out lines of code above, fails to contain the required
fields with their default values. If I poke around the 'type'
variable in the debugger, I can see that the 2 fields are in the
descriptor, and the default values are there as well. But the
instance of the message does not contain those two fields
(dmFields.entrySet() returns null, and the code inside the
for(EntryFieldDescriptor, Object entry : dmFields.entrySet()) loop
does not execute).
It seems like I could write a routine to set the default values based
on the Descriptor data, but I think that getDefaultInstance should do
that for me.
Thoughts?
Thanks,
Kevin
On Mar 22, 4:02 pm, Kenton Varda ken...@google.com wrote:
DescriptorProto.getDescriptorForType() returns the Descriptor for
DescriptorProto, not for the type which that DescriptorProto is
describing.
Remember that DescriptorProto is just a protocol message like any
other
--
it does not have any special methods that recognize its higher-level
meaning.
To convert DescriptorProtos to Descriptors, you need to use
FileDescriptor.buildFrom().
On Sun, Mar 21, 2010 at 5:20 PM, Kevin Tambascio
kevin.tambas...@gmail.comwrote:
Hi,
I'm having trouble getting the following code to work. Using
protoc.exe, I generated a file with the
