[PATCH] Fix super().__init__ call on python2.6
In 2.4, 2.5 and 2.6 superclass constructor call don't need self as first arg but 2.6 raises error if it's given. --- python/google/protobuf/reflection.py |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/python/google/protobuf/reflection.py b/python/google/protobuf/reflection.py index d80942e..25dd04b 100755 --- a/python/google/protobuf/reflection.py +++ b/python/google/protobuf/reflection.py @@ -152,7 +152,7 @@ class GeneratedProtocolMessageType(type): _AddMessageMethods(descriptor, cls) _AddPrivateHelperMethods(cls) superclass = super(GeneratedProtocolMessageType, cls) -superclass.__init__(cls, name, bases, dictionary) +superclass.__init__(name, bases, dictionary) # Stateless helpers for GeneratedProtocolMessageType below. -- 1.5.6.5 --~--~-~--~~~---~--~~ 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: Make check reports error
I've fixed the sparc bug in SVN (revision 72). The bug is only a problem if
you use DynamicMessage; otherwise you can stick with 2.0.2.
On Thu, Oct 23, 2008 at 11:55 PM, Niclas Blomgren <
[EMAIL PROTECTED]> wrote:
> Hi again!
>
> Ok I didn't know that. When I from cygwin execute "ls c:" it works fine.
> But if I try "touch c:\trashfile" then I get permission denied. Weird. I
> agree that I can ignore this problem.
>
> Ok I guess I will have to hope that the sparc failure doesn't cause me any
> trouble then.
>
> Thanks for your support.
>
> BR / N
>
> --
> *From:* Kenton Varda [mailto:[EMAIL PROTECTED]
> *Sent:* den 23 oktober 2008 22:31
>
> *To:* Niclas Blomgren
> *Cc:* protobuf@googlegroups.com
> *Subject:* Re: Make check reports error
>
> Cygwin allows you to specify paths like "C:\". For example, try this
> command:
> ls 'C:\'
>
> At least, for me, this lists the root of the C drive. It looks like the
> test failed because you do not have permission to access C:\ on your
> machine. Is this possible? You can probably ignore this failure.
>
> The sparc failure is still mysterious to me. Unfortunately I don't have a
> sparc machine on which I can debug it. :(
>
> On Thu, Oct 23, 2008 at 1:22 AM, Niclas Blomgren <
> [EMAIL PROTECTED]> wrote:
>
>> Hi again,
>>
>> I took a quick look at this code in command_line_interface_unittest.cc
>>
>> TEST_F(CommandLineInterfaceTest, WindowsOutputPath) {
>> // Test that the output path can be a Windows-style path.
>>
>> NullCodeGenerator* generator = RegisterNullGenerator("--test_out");
>>
>> CreateTempFile("foo.proto",
>> "syntax = \"proto2\";\n");
>>
>> Run("protocol_compiler --test_out=C:\\ "
>> "--proto_path=$tmpdir foo.proto");
>>
>> ExpectNoErrors();
>> EXPECT_TRUE(generator->called_);
>> EXPECT_EQ("", generator->parameter_);
>> }
>>
>> At a quick glance it seems like the code tries to access C:.
>> In cygwin however the path to C: is /cygdrive/c.
>>
>> BR / N
>>
>>
>> --
>> *From:* Niclas Blomgren
>> *Sent:* den 23 oktober 2008 09:50
>> *To:* 'Kenton Varda'
>> *Cc:* protobuf@googlegroups.com
>> *Subject:* RE: Make check reports error
>>
>> Hi!
>>
>> Solaris: Yes it was a sparc system. 64-bit.
>>
>> Cygwin: Ok here it is. I have also attached the entire "make check " in a
>> logfile.
>>
>> [ RUN ] CommandLineInterfaceTest.WindowsOutputPath
>> google/protobuf/compiler/command_line_interface_unittest.cc:329: Failure
>> Value of: return_code_
>> Actual: 1
>> Expected: 0
>> google/protobuf/compiler/command_line_interface_unittest.cc:330: Failure
>> Value of: error_text_
>> Actual: "C:\/: Permission denied
>> "
>> Expected: ""
>> google/protobuf/compiler/command_line_interface_unittest.cc:522: Failure
>> Value of: generator->called_
>> Actual: false
>> Expected: true
>> [ FAILED ] CommandLineInterfaceTest.WindowsOutputPath
>> [ RUN ] CommandLineInterfaceTest.WindowsOutputPathAndParameter
>> google/protobuf/compiler/command_line_interface_unittest.cc:329: Failure
>> Value of: return_code_
>> Actual: 1
>> Expected: 0
>> google/protobuf/compiler/command_line_interface_unittest.cc:330: Failure
>> Value of: error_text_
>> Actual: "C:\/: Permission denied
>> "
>> Expected: ""
>> google/protobuf/compiler/command_line_interface_unittest.cc:538: Failure
>> Value of: generator->called_
>> Actual: false
>> Expected: true
>> google/protobuf/compiler/command_line_interface_unittest.cc:539: Failure
>> Value of: generator->parameter_
>> Actual: ""
>> Expected: "bar"
>> [ FAILED ] CommandLineInterfaceTest.WindowsOutputPathAndParameter
>>
>>
>>
>> Hopeing you can help me.
>> Best Regards / Niclas Blomgren
>>
>>
>> --
>> *From:* Kenton Varda [mailto:[EMAIL PROTECTED]
>> *Sent:* den 23 oktober 2008 00:19
>> *To:* Niclas Blomgren
>> *Cc:* protobuf@googlegroups.com
>> *Subject:* Re: Make check reports error
>>
>> On Wed, Oct 22, 2008 at 7:23 AM, Niclas Blomgren <
>> [EMAIL PROTECTED]> wrote:
>>
>>> Solaris:
>>>
>> I'm guessing this was a sparc system, not x86? Was it 32-bit or 64-bit?
>> I think someone else reported the same problem but we were not able to
>> track it down.
>>
>>> Cygwin:
>>>
>> Can you include the text of the actual failures in your log? (You only
>> included the summary.)
>>
>
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Sparc 64-bit bug fixed
I just submitted revision 72, which fixes the bug that caused the tests to crash on 64-bit sparc machines. It turns out DynamicMessage computed some byte offsets incorrectly leading to alignment problems. The new code should be more robust. I'll probably do a 2.0.3 release within the next week or two to get all these bug fixes out there. --~--~-~--~~~---~--~~ 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: Interface and Implementation
On Nov 7, 11:06 am, Kenton Varda <[EMAIL PROTECTED]> wrote: > I think either approach can work, and the trade-offs depend on your > application. If your protocol messages are very complex, for instance, then > maintaining parallel C++ classes can be a huge pain. On the other hand, > protocol message classes are essentially structs, whereas with hand-written > C++ classes you can do better data encapsulation and such. > As far as overhead goes, protocol message objects are approximately > equivalent to structs in both size and access speed, so there's not much to > worry about there. Avoiding the conversion between protobufs and internal > structures may save time. This is encouraging - it removes my worries about the overhead of using them widely. > On the other hand, if your data doesn't fit well > into the protobuf model, it may be less efficient than it could be. For > example, if you are representing a graph, you cannot have each node contain > pointers to all nodes it connects with, because protocol messages must be > tree-shaped. I think that internally I will still be using STL containers to hold collections of messages in various forms. The container itself does the job of defining the relationship between messages (list, set, tree, etc), so there shouldn't be a conflict. I will provide RPC functions that provide external applications a functional interface to the internal structures. This makes it an easy separation & means I don't have to double up the work with internal data structures. > Bottom line is, there's no definitive answer, and you'll need to weigh the > trade-offs in the context of your application. Thanks for the useful feedback, Jeff --~--~-~--~~~---~--~~ 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: Interface and Implementation
I think either approach can work, and the trade-offs depend on your application. If your protocol messages are very complex, for instance, then maintaining parallel C++ classes can be a huge pain. On the other hand, protocol message classes are essentially structs, whereas with hand-written C++ classes you can do better data encapsulation and such. As far as overhead goes, protocol message objects are approximately equivalent to structs in both size and access speed, so there's not much to worry about there. Avoiding the conversion between protobufs and internal structures may save time. On the other hand, if your data doesn't fit well into the protobuf model, it may be less efficient than it could be. For example, if you are representing a graph, you cannot have each node contain pointers to all nodes it connects with, because protocol messages must be tree-shaped. Bottom line is, there's no definitive answer, and you'll need to weigh the trade-offs in the context of your application. On Thu, Nov 6, 2008 at 2:44 PM, codeazure <[EMAIL PROTECTED]> wrote: > > On Nov 7, 7:14 am, Kenton Varda <[EMAIL PROTECTED]> wrote: > > I've read your message a few times now and I have to admit I don't really > > understand what you're getting at. Can you give a small example of each > of > > the approaches you're considering? > > Sorry, I was a bit obtuse. I am considering two different approaches > to application design using PB. > > One design approach is to use the Facade design pattern and only use > PB data structures in the interface. Within a module, I use hand > written C++ data structures only & only pass these between modules > within the application. Then, there is a separate section of the > application that defines .proto files and their generated C++ files. > Interface functions translate the internal classes into the matching > PB messages and RPC declarations for external applications to use. > > A specific example of what this means is that if I have a variable > that may or may not be used, I might implement this using > boost::optional in my internal code. In the PB interface, I would > translate this into an extension that may or may not be defined in a > message. > > An alternative approach is to use PB message structures throughout the > module. All the code would use the PB generated functions for handling > extensions, accessor functions and so on. > > I understand that the primary aim of PB is for serialization of > messages. However, having all the support functionality for > extensions, and the accessor functions is handy in general > programming. If I use PB generated C++ data structures everywhere, > then it makes my application more flexible, making it easier to break > into pieces across multiple computers for example. > > The reason I'm hesitant about using PB data structures everywhere is > that I don't know what the memory and processing overhead is of using > them. > > I hope this makes my question clearer. > > Thanks, > Jeff > > > On Wed, Nov 5, 2008 at 12:06 AM, codeazure <[EMAIL PROTECTED]> wrote: > > > > > Does anyone have any thoughts on the use of PB message definitions for > > > interface only or throughout the implementation code as well? > > > > > I am planning a very modular application, where each module uses PB as > > > it's interface to external applications and inter-machine > > > communications within itself. > > > > > Should I be only writing PB definitions, generating C++ files and only > > > using those? Or should I write C++ headers with the implementation > > > version and only use PB for the interface? > > > > > I can easily imagine using a PB generated header file in my > > > implementation, calling the accessor functions & taking advantage of > > > the other support features in the Message class. But I'm not sure if > > > this is a good approach. > > > > > I understand that function calls are a different question & I should > > > only use RPC definitions when I am actually connecting to a remote > > > application, and not for internal function calls. > > > > > To put it another way, should I use the Bridge (or possibly Facade) > > > design pattern when using PB or should my data structures be defined > > > in one place only? > > > > > Thanks, > > > Jeff > > > --~--~-~--~~~---~--~~ 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: Interface and Implementation
On Nov 7, 7:14 am, Kenton Varda <[EMAIL PROTECTED]> wrote: > I've read your message a few times now and I have to admit I don't really > understand what you're getting at. Can you give a small example of each of > the approaches you're considering? Sorry, I was a bit obtuse. I am considering two different approaches to application design using PB. One design approach is to use the Facade design pattern and only use PB data structures in the interface. Within a module, I use hand written C++ data structures only & only pass these between modules within the application. Then, there is a separate section of the application that defines .proto files and their generated C++ files. Interface functions translate the internal classes into the matching PB messages and RPC declarations for external applications to use. A specific example of what this means is that if I have a variable that may or may not be used, I might implement this using boost::optional in my internal code. In the PB interface, I would translate this into an extension that may or may not be defined in a message. An alternative approach is to use PB message structures throughout the module. All the code would use the PB generated functions for handling extensions, accessor functions and so on. I understand that the primary aim of PB is for serialization of messages. However, having all the support functionality for extensions, and the accessor functions is handy in general programming. If I use PB generated C++ data structures everywhere, then it makes my application more flexible, making it easier to break into pieces across multiple computers for example. The reason I'm hesitant about using PB data structures everywhere is that I don't know what the memory and processing overhead is of using them. I hope this makes my question clearer. Thanks, Jeff > On Wed, Nov 5, 2008 at 12:06 AM, codeazure <[EMAIL PROTECTED]> wrote: > > > Does anyone have any thoughts on the use of PB message definitions for > > interface only or throughout the implementation code as well? > > > I am planning a very modular application, where each module uses PB as > > it's interface to external applications and inter-machine > > communications within itself. > > > Should I be only writing PB definitions, generating C++ files and only > > using those? Or should I write C++ headers with the implementation > > version and only use PB for the interface? > > > I can easily imagine using a PB generated header file in my > > implementation, calling the accessor functions & taking advantage of > > the other support features in the Message class. But I'm not sure if > > this is a good approach. > > > I understand that function calls are a different question & I should > > only use RPC definitions when I am actually connecting to a remote > > application, and not for internal function calls. > > > To put it another way, should I use the Bridge (or possibly Facade) > > design pattern when using PB or should my data structures be defined > > in one place only? > > > Thanks, > > Jeff --~--~-~--~~~---~--~~ 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: separate files per each message type
Thanks Kenton. I got it by now :) Is it written in the docs? If not, it should be. Thanks again - it's a wonderful tool. Cheers, Omer On Thu, Nov 6, 2008 at 10:11 PM, Kenton Varda <[EMAIL PROTECTED]> wrote: > You would have to define each message in a separate .proto file. > > On Thu, Nov 6, 2008 at 1:37 AM, <[EMAIL PROTECTED]> wrote: > >> >> Hi guys! >> >> I'm a new user. >> >> Can somebody kindly tell me how do I generate classes in separate >> files (h' and cpp' files for each message)? >> >> Thanks! >> Omer >> >> >> > --~--~-~--~~~---~--~~ 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: Interface and Implementation
Hi Jeff, I've read your message a few times now and I have to admit I don't really understand what you're getting at. Can you give a small example of each of the approaches you're considering? On Wed, Nov 5, 2008 at 12:06 AM, codeazure <[EMAIL PROTECTED]> wrote: > > Does anyone have any thoughts on the use of PB message definitions for > interface only or throughout the implementation code as well? > > I am planning a very modular application, where each module uses PB as > it's interface to external applications and inter-machine > communications within itself. > > Should I be only writing PB definitions, generating C++ files and only > using those? Or should I write C++ headers with the implementation > version and only use PB for the interface? > > I can easily imagine using a PB generated header file in my > implementation, calling the accessor functions & taking advantage of > the other support features in the Message class. But I'm not sure if > this is a good approach. > > I understand that function calls are a different question & I should > only use RPC definitions when I am actually connecting to a remote > application, and not for internal function calls. > > To put it another way, should I use the Bridge (or possibly Facade) > design pattern when using PB or should my data structures be defined > in one place only? > > Thanks, > Jeff > > > --~--~-~--~~~---~--~~ 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: separate files per each message type
You would have to define each message in a separate .proto file. On Thu, Nov 6, 2008 at 1:37 AM, <[EMAIL PROTECTED]> wrote: > > Hi guys! > > I'm a new user. > > Can somebody kindly tell me how do I generate classes in separate > files (h' and cpp' files for each message)? > > Thanks! > Omer > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
separate files per each message type
Hi guys! I'm a new user. Can somebody kindly tell me how do I generate classes in separate files (h’ and cpp’ files for each message)? Thanks! Omer --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
