[protobuf] Visual Studio Visualizer for Repeated Messages

2010-01-18 Thread naderp
Hi

Back in 2.0.3 I was able to visualise repeated messages under the VS C+
+ 2008 debugger. In 2.2.0 they are no longer inspectable.

Can anyone shed any light on this or maybe submit a visualiser?

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] Building on Solaris 9

2010-01-18 Thread Kenton Varda
GCC 2.7.2 is nearly a decade old.  It's highly unlikely that you could get
it to compile protocol buffers without lots and lots of work.  You'll need
to use a newer compiler, such as GCC 3 or 4.

On Mon, Jan 18, 2010 at 11:11 AM, Jeff jeff_...@appsig.com wrote:

 Trying to compile Protocol Buffers 2.2.0 on a Solaris 9 box.
 It is failing when compiling the pre-compiler tool but the compile
 error seems to be regarding the stub code found in google/protobuf/
 stubs/.  I just did the typical configure (except disablilng the 64
 bit option) and then make from the base directory.  I do realize
 this is an archaic system but thats what I'm stuck with.

 Here are the details:

 From uname -a:
 Sun OS 5.9 Generic_122300-15 sun4u sparc SUNW,Sun-Fire-V210

 Both g++ and gcc are version 2.7.2 (in /usr/local)

 Configure String (note the disabling of 64 bit):
 ./configure --prefix=/users/jmay/sdks --disable-64bit-solaris

 Compiler String:
 g++ -DHAVE_CONFIG_H -I. -I.. -Wall -Wwrite-strings -Woverloaded-
 virtual -Wno-sign-compare -O2 -g -DNDEBUG -c -o main.o

 Errors:
 cc1plus: Invalid option '-Wno-sign-compare'
 google/protobuf/stubs/common.h:143: parse error before ';'
 google/protobuf/stubs/common.h:143: warning: ANSI C++ forbids
 declaration 'int64' with no type or storage class

 It then continues to complain about numerous other 64 bit types
 (uint64, kint64max, kint64min, kuint64max)

 Any ideas? Thanks in advance.

 --
 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] Why not to allow [packed = true] for all repeated field?

2010-01-18 Thread Kenton Varda
In addition to what Henner says, we felt that it wasn't worthwhile to
implement packed encoding for strings or sub-messages because the savings
would be very small.  The packed encoding only saves one or two bytes per
element.

On Sun, Jan 17, 2010 at 7:30 PM, Henner Zeller henner.zel...@googlemail.com
 wrote:

 On Sun, Jan 17, 2010 at 18:59, Atry pop.a...@gmail.com wrote:
  When I set [packed = true] on a nested message field, I receive this
 error:
 
  [packed = true] can only be specified for repeated primitive fields.
 
  I wonder why it is disallowed.

 The reason is to be able to automatically distinguish fields that have
 been 'upgraded' from previously non-packed to packed.
 This detection can be done because the type on the wire changes for
 primitive types but it would not change for non-primitive types.

 An example: a non-packed repeated field for a primitive type would be
 on the wire something like tag, int-type value tag, int-type
 value ...
 That would change for packed to something like tag,
 length-delimited-type length [value value value ...]

 While if it was a length delimited field in the first place, say a
 string or a message, that type on the wire length-delimited would
 not change, so it is impossible to distinguish just from the raw byte
 sequence if this is a length non-packed or a packed repeated field.
 Dropping the feature for length delimited fields (for which there is
 not much saving to be expected anyway) allows for a safe upgrade path.

  The output for packed nested field list as
  the below:
 
  The field number and wire type LENGTH_DELIMITED.
  Length of all elements.
  Length of the first element.
  Content of the first element.
  Length of the second element.
  Content of the second element.
 
  ...
 
  Length of the nth element.
  Content of the nth element.
 
  --
  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.