Re: 2.0.2 release is up

2008-10-13 Thread edan 

Nope - indeed it doesn't work :(

Unfortunately I am not (yet) enough of a C++ superstar to tinker much
with that code.

What I did try was to borrow someone else's updated environment and
try to compile there using gcc 4.1.2
So...

descriptor.cc does seem to compile under gcc 4.1.2!  That's the good
news, and pretty much what we expected.

I do get a bunch of warnings though:

 g++ -DHAVE_CONFIG_H -I. -I. -I.. -pthread -Wall -Wwrite-strings -
Woverloaded-virtual -Wno-sign-compare -g -O2 -MT descriptor.lo -MD -MP
-MF .deps/descriptor.Tpo -c google/protobuf/descriptor.cc  -fPIC -DPIC
-o .libs/descriptor.o
google/protobuf/descriptor.cc:268: warning:
'google::protobuf::DescriptorPool::Tables' has a field
'google::protobuf::DescriptorPool::Tables::symbols_by_name_' whose
type uses the anonymous namespace
google/protobuf/descriptor.cc:268: warning:
'google::protobuf::DescriptorPool::Tables' has a field
'google::protobuf::DescriptorPool::Tables::symbols_by_parent_' whose
type uses the anonymous namespace
google/protobuf/descriptor.cc:268: warning:
'google::protobuf::DescriptorPool::Tables' has a field
'google::protobuf::DescriptorPool::Tables::files_by_name_' whose type
uses the anonymous namespace
google/protobuf/descriptor.cc:268: warning:
'google::protobuf::DescriptorPool::Tables' has a field
'google::protobuf::DescriptorPool::Tables::fields_by_number_' whose
type uses the anonymous namespace
google/protobuf/descriptor.cc:268: warning:
'google::protobuf::DescriptorPool::Tables' has a field
'google::protobuf::DescriptorPool::Tables::enum_values_by_number_'
whose type uses the anonymous namespace
google/protobuf/descriptor.cc:1761: warning:
'google::protobuf::DescriptorBuilder::OptionInterpreter' has a field
'google::protobuf::DescriptorBuilder::OptionInterpreter::options_to_interpret_'
whose type uses the anonymous namespace
google/protobuf/descriptor.cc:1598: warning:
'google::protobuf::DescriptorBuilder' has a field
'google::protobuf::DescriptorBuilder::options_to_interpret_' whose
type uses the anonymous namespace
 g++ -DHAVE_CONFIG_H -I. -I. -I.. -pthread -Wall -Wwrite-strings -
Woverloaded-virtual -Wno-sign-compare -g -O2 -MT descriptor.lo -MD -MP
-MF .deps/descriptor.Tpo -c google/protobuf/descriptor.cc -o
descriptor.o /dev/null 21

I quick google didn't turn up much for me on what that actually means
- does it mean anything to y'all?

In any case, using gcc 4.1.2, make and make check (any reason you
didn't use the more standard make test?) succeeded for me, so I
guess I will have to just wait to update to protobuf-2.0.2 until I can
move myself to the newer gcc.

Thanks in any case for the help.

--edan

On Oct 8, 9:07 pm, Kenton Varda [EMAIL PROTECTED] wrote:
 OK, based on sephacryl's message I created this patch, but I suspect edan's
 problem is actually different.  Can you both try it out and tell me if it
 works?  edan, if this doesn't solve the problem for you, can you try making
 some changes yourself and figure out what works?
 Index: src/google/protobuf/descriptor.cc
 ===
 --- src/google/protobuf/descriptor.cc   (revision 65)
 +++ src/google/protobuf/descriptor.cc   (working copy)
 @@ -1693,6 +1693,9 @@
    templateclass DescriptorT void AllocateOptions(
        const typename DescriptorT::OptionsType orig_options,
        DescriptorT* descriptor);
 +  // Specialization for FileOptions.
 +  void AllocateOptions(const FileOptions orig_options,
 +                       FileDescriptor* descriptor);

    // Implementation for AllocateOptions(). Don't call this directly.
    templateclass DescriptorT void AllocateOptionsImpl(
 @@ -2208,9 +2211,8 @@
  }

  // We specialize for FileDescriptor.
 -template void DescriptorBuilder::AllocateOptionsFileDescriptor(
 -    const FileDescriptor::OptionsType orig_options,
 -    FileDescriptor* descriptor) {
 +void DescriptorBuilder::AllocateOptions(const FileOptions orig_options,
 +                                        FileDescriptor* descriptor) {
    // We add the dummy token so that LookupSymbol does the right thing.
    AllocateOptionsImpl(descriptor-package() + .dummy, descriptor-name(),
                        orig_options, descriptor);

 On Tue, Oct 7, 2008 at 10:05 PM, [EMAIL PROTECTED] wrote:

  What works is adding to the definition of class DescriptorBuilder to
  line1696,

   void AllocateOptions(
       const typename FileDescriptor::OptionsType orig_options,
       FileDescriptor* descriptor);

  And changing the implementation, removing the template specialization,
  at line 2213 to:

  void DescriptorBuilder::AllocateOptions(
     const FileDescriptor::OptionsType orig_options,
     FileDescriptor* descriptor) {
   // We add the dummy token so that LookupSymbol does the right thing.
   AllocateOptionsImpl(descriptor-package() + .dummy, descriptor-
  name(),
                       orig_options, descriptor);
  }

  This is not incorrect either since it implements function

Re: invalid tag (zero)

2008-10-13 Thread Kenton Varda 
Are you sure that the data you are sending to the parser is exactly the same
data that was generated by the serializer?  Remember that protocol buffers
are not self-delimiting, so you need to make sure that you limit the input
to the exact number of bytes that were produced when serializing.
If the data is exactly the same, then this is a bug.  If you can create a
small program or pair of programs that demonstrate the problem, I would be
happy to debug it.

On Mon, Oct 13, 2008 at 10:09 AM, Dominik Steenken [EMAIL PROTECTED] wrote:


 Hi everyone,

  we are currrently implementing a server/client system, the server
 being implemented in c++, the client in java. During our last rounds
 of tests, we encountered a problem that had to do with the sending of
 (not so) long messages. on the (receiving) java side, we get the
 following exception:
  Exception in augnet.client.aim.connection.Receiver, Parse error:
 com.google.protobuf.InvalidProtocolBufferException: Protocol message
 contained an invalid tag (zero).
 com.google.protobuf.InvalidProtocolBufferException: Protocol message
 contained an invalid tag (zero).
at

 com.google.protobuf.InvalidProtocolBufferException.invalidTag(InvalidProtocolBufferException.java:
 52)
at
 com.google.protobuf.CodedInputStream.readTag(CodedInputStream.java:
 67)
at com.google.protobuf.FieldSet.mergeFrom(FieldSet.java:397)
at com.google.protobuf.AbstractMessage
 $Builder.mergeFrom(AbstractMessage.java:248)
at com.google.protobuf.GeneratedMessage
 $Builder.mergeFrom(GeneratedMessage.java:1)
at
 com.google.protobuf.CodedInputStream.readMessage(CodedInputStream.java:
 227)
at com.google.protobuf.FieldSet.mergeFieldFrom(FieldSet.java:482)
at com.google.protobuf.FieldSet.mergeFrom(FieldSet.java:402)
at com.google.protobuf.AbstractMessage
 $Builder.mergeFrom(AbstractMessage.java:248)
at com.google.protobuf.GeneratedMessage
 $Builder.mergeFrom(GeneratedMessage.java:1)
at
 com.google.protobuf.CodedInputStream.readMessage(CodedInputStream.java:
 227)
at com.google.protobuf.FieldSet.mergeFieldFrom(FieldSet.java:482)
at com.google.protobuf.FieldSet.mergeFrom(FieldSet.java:402)
at com.google.protobuf.AbstractMessage
 $Builder.mergeFrom(AbstractMessage.java:248)
at com.google.protobuf.AbstractMessage
 $Builder.mergeFrom(AbstractMessage.java:240)
at com.google.protobuf.AbstractMessage
 $Builder.mergeFrom(AbstractMessage.java:298)
at augnet.client.aim.messages.MessageProtos
 $AugNetMessage.parseFrom(MessageProtos.java:6289)
at augnet.client.aim.connection.Receiver.run(Receiver.java:47)

 while the (sending) c++ side encounters no errors. When we scale down
 the message, no error occurs. Is this a bug in protobuf or are we
 doing something wrong?

 Best regards,
  Dominik
 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Re: 2.0.2 release is up

2008-10-13 Thread Kenton Varda 
On Mon, Oct 13, 2008 at 2:26 AM, edan [EMAIL PROTECTED] wrote:

 I quick google didn't turn up much for me on what that actually means
 - does it mean anything to y'all?


Yes, this was an overzealous warning present in one version of GCC which was
promptly toned down in subsequent versions.  You can ignore it.


 In any case, using gcc 4.1.2, make and make check (any reason you
 didn't use the more standard make test?) succeeded for me, so I
 guess I will have to just wait to update to protobuf-2.0.2 until I can
 move myself to the newer gcc.


I'll try to look into this more when I get a chance.  You should be fine
sticking with 2.0.1, though, as long as you weren't hoping to use the new
custom options feature.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Re: How can I compile the protobuf with stlport?

2008-10-13 Thread Kenton Varda 
Does stlport's hash_map work like SGI's hash_map, or like MSVC's hash_map,
or does it do its own thing?  A brief look at the docs suggest that it is
most similar to SGI's.  In that case, you should only need to change the
#ifdefs in src/google/protobuf/stubs/hash.h so that your compile takes the
non-MSVC branch.  That is, change line 101 from:
  #elif defined(_MSC_VER)

to:

  #elif 0

Let me know if this works.

On Mon, Oct 13, 2008 at 3:08 AM, [EMAIL PROTECTED] wrote:


 thanks. it's okay, but i am thinking how to use stlport's hash_map
 with protobuf.
 how can i do?

 On 10月11日, 上午4时24分, Kenton Varda [EMAIL PROTECTED] wrote:
  I'm not familiar with stlport.  One thing you could try doing is editing
  config.h manually and removing all the HASH_* #defines.  Then the code
 will
  fall back to using map instead of hash_map, which should work since map
 has
  a standard interface.
 
  On Fri, Oct 10, 2008 at 2:58 AM, [EMAIL PROTECTED] wrote:
 
   I'm using stlport, and i want to use protobuf, but I see some
   compiling errors about the hash_map.
 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---