Recursive import problem

2009-08-13 Thread Justin Muncaster

I have the following message structure:

===A.proto===
message A
{
  optional B1 b1 = 1;
}

message B1
{
  optional A a = 1;
}

Everything works as intended when the messages are in the same file.
However, in my situation there are several child messages (B2,
B3, ...) which all naturally all go in their own separate files
(B2.proto, B3.proto, ...). Unfortunately, B1 cannot go in its own file
due to a problem with a recursive import.

Is there any way to solve this? Can I forward declare messages?

Thanks,

Justin

--~--~-~--~~~---~--~~
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 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---



Re: protobuf HPUX support

2009-08-13 Thread Kenton Varda
Please send a patch.  Use diff -u to create it (see the man page), or if
you made your changes against the SVN sources, just use svn diff.

On Wed, Aug 12, 2009 at 10:08 PM, COFF a...@sibmail.ru wrote:


 Hello Kenton!

 I succesfully merge my project on new version of protobuf.
 I made patches that enable HPUX (and partialy STLPORT) support in
 protobuf (only .cc and .h - I not use autoconf stuff).
 Can and how I send it to you?


 Best regards,
 Alex.

 


--~--~-~--~~~---~--~~
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 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---



Re: Recursive import problem

2009-08-13 Thread Kenton Varda
Sorry, but mutually recursive messages must be declared in a single file.
 It would be excessively complicated to support cyclically dependent files
under the current implementation.

On Thu, Aug 13, 2009 at 11:34 AM, Justin Muncaster 
justin.muncas...@gmail.com wrote:


 I have the following message structure:

 ===A.proto===
 message A
 {
  optional B1 b1 = 1;
 }

 message B1
 {
  optional A a = 1;
 }

 Everything works as intended when the messages are in the same file.
 However, in my situation there are several child messages (B2,
 B3, ...) which all naturally all go in their own separate files
 (B2.proto, B3.proto, ...). Unfortunately, B1 cannot go in its own file
 due to a problem with a recursive import.

 Is there any way to solve this? Can I forward declare messages?

 Thanks,

 Justin

 


--~--~-~--~~~---~--~~
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 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---



Protobuf-lite and ParseFromIstream/SerializeToOstream

2009-08-13 Thread Handyman

Those serializers seem to have been taken out for the MessageLite
implementation.  I'm migrating old code to the lite implementation --
I just create a std::ifstream/std::ofstream and hand it off to Message
in my old code.  Whats the best way to do this in the new code?  The
CodedStream stuff looks on point but the docs seem to imply that I'm
getting into deep internals by considering them.

--~--~-~--~~~---~--~~
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 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---



Re: Protobuf-lite and ParseFromIstream/SerializeToOstream

2009-08-13 Thread Kenton Varda
Deciding exactly where to draw the line for lite mode was hard -- different
users want different things.
There's two reasonable options here:

1) Read the entire istream to a string first, then call ParseFromString.
 Similarly, when writing, use SerializeToString() then write the entire
string to the ostream.

2) Go into the protobuf source and pull out
src/google/protobuf/io/zero_copy_stream_impl.*.  Find the classes for
reading from and writing to iostreams and copy them into your own project
code.  Then use ParseFromZeroCopyStream() and SerializeToZeroCopyStream()
with those classes.

Option (1) is simpler but (2) may be a little bit more efficient if your
messages are fairly large (probably around 100k or more).

On Thu, Aug 13, 2009 at 3:48 PM, Handyman david...@gmail.com wrote:


 Those serializers seem to have been taken out for the MessageLite
 implementation.  I'm migrating old code to the lite implementation --
 I just create a std::ifstream/std::ofstream and hand it off to Message
 in my old code.  Whats the best way to do this in the new code?  The
 CodedStream stuff looks on point but the docs seem to imply that I'm
 getting into deep internals by considering them.

 


--~--~-~--~~~---~--~~
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 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---



Re: Protobuf-lite and ParseFromIstream/SerializeToOstream

2009-08-13 Thread Handyman

Thanks.  That'll help.  I'll try the second approach you mentioned (my
messages are not complex but the chunks of data are fairly large --
often well over 100k so I didn't want to use solution #1).  If there
are any hiccups I'll post them here for posterity.

There is no answer to the question of what should go in the lite
version.  I, for one, am totally thrilled with the way it was
integrated.  All *I* miss is this native std::stream support and
solution #1 was an obvious workaround.  Thanks for the great work!

- David



On Aug 13, 3:56 pm, Kenton Varda ken...@google.com wrote:
 Deciding exactly where to draw the line for lite mode was hard -- different
 users want different things.
 There's two reasonable options here:

 1) Read the entire istream to a string first, then call ParseFromString.
  Similarly, when writing, use SerializeToString() then write the entire
 string to the ostream.

 2) Go into the protobuf source and pull out
 src/google/protobuf/io/zero_copy_stream_impl.*.  Find the classes for
 reading from and writing to iostreams and copy them into your own project
 code.  Then use ParseFromZeroCopyStream() and SerializeToZeroCopyStream()
 with those classes.

 Option (1) is simpler but (2) may be a little bit more efficient if your
 messages are fairly large (probably around 100k or more).

 On Thu, Aug 13, 2009 at 3:48 PM, Handyman david...@gmail.com wrote:

  Those serializers seem to have been taken out for the MessageLite
  implementation.  I'm migrating old code to the lite implementation --
  I just create a std::ifstream/std::ofstream and hand it off to Message
  in my old code.  Whats the best way to do this in the new code?  The
  CodedStream stuff looks on point but the docs seem to imply that I'm
  getting into deep internals by considering them.
--~--~-~--~~~---~--~~
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 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---



Re: protobuf HPUX support

2009-08-13 Thread COFF

I does not find how to attach files in this group,
and simple paste it in message.

On 14 авг, 02:24, Kenton Varda ken...@google.com wrote:
 Please send a patch.  Use diff -u to create it (see the man page), or if
 you made your changes against the SVN sources, just use svn diff.

 On Wed, Aug 12, 2009 at 10:08 PM, COFF a...@sibmail.ru wrote:

  Hello Kenton!

  I succesfully merge my project on new version of protobuf.
  I made patches that enable HPUX (and partialy STLPORT) support in
  protobuf (only .cc and .h - I not use autoconf stuff).
  Can and how I send it to you?

  Best regards,
  Alex.


--~--~-~--~~~---~--~~
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 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---



Re: protobuf HPUX support

2009-08-13 Thread COFF

I sent patches directly to you.
Note on adding  also VC 7.1 support (macro EXPECT_EQ produse Internal
Compiller Error on non const std::string)

On 14 авг, 02:24, Kenton Varda ken...@google.com wrote:
 Please send a patch.  Use diff -u to create it (see the man page), or if
 you made your changes against the SVN sources, just use svn diff.

 On Wed, Aug 12, 2009 at 10:08 PM, COFF a...@sibmail.ru wrote:

  Hello Kenton!

  I succesfully merge my project on new version of protobuf.
  I made patches that enable HPUX (and partialy STLPORT) support in
  protobuf (only .cc and .h - I not use autoconf stuff).
  Can and how I send it to you?

  Best regards,
  Alex.


--~--~-~--~~~---~--~~
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 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---



Re: protobuf HPUX support

2009-08-13 Thread Kenton Varda
Instead of changing everything that calls EXPECT_EQ on strings, can we
change the implementation of EXPECT_EQ itself so that doesn't trigger this
error?  For example, could it be overloaded with an explicit implementation
for non-const strings?
Any changes to gtest will have to be submitted back to the gtest project.
 Protocol Buffers ships with the verbatim gtest code -- we don't maintain
local modifications.

On Thu, Aug 13, 2009 at 7:47 PM, COFF a...@sibmail.ru wrote:


 I sent patches directly to you.
 Note on adding  also VC 7.1 support (macro EXPECT_EQ produse Internal
 Compiller Error on non const std::string)

 On 14 авг, 02:24, Kenton Varda ken...@google.com wrote:
  Please send a patch.  Use diff -u to create it (see the man page), or
 if
  you made your changes against the SVN sources, just use svn diff.
 
  On Wed, Aug 12, 2009 at 10:08 PM, COFF a...@sibmail.ru wrote:
 
   Hello Kenton!
 
   I succesfully merge my project on new version of protobuf.
   I made patches that enable HPUX (and partialy STLPORT) support in
   protobuf (only .cc and .h - I not use autoconf stuff).
   Can and how I send it to you?
 
   Best regards,
   Alex.
 
 
 


--~--~-~--~~~---~--~~
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 
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---