Re: Deleting one of a repeated field?
reply to self: I guess you copy the item from the end of the list into the space formerly occupied by the item you want to delete, then call RemoveLast()... On Sep 16, 4:27 pm, [EMAIL PROTECTED] wrote: OK, rephrase that question. Say you have a releated field containing 10 items. You wish to delete the 2nd item so that the list contains 9 items and foo_size() returns 9. Is that possible? I can't see an erase() function in mutable_foo(), and I can't see anything in RepeatedField that decrements current_size_ other than RemoveLast() which presumably will only remove the _last_ item? Currently the only way to remove elements from a list seems to be awful hacks like a.parse(a.serialise()) after clearing the items you want to delete On Aug 12, 9:05 pm, Kenton Varda [EMAIL PROTECTED] wrote: For C++, use the RepeatedField interfaces:http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google... You can get a mutable pointer to a RepeatedField or RepeatedPtrField that represents a field named foo by calling the message's mutable_foo() accessor. For Python, I think you currently have to clear the field and repopulate it. On Tue, Aug 12, 2008 at 12:22 PM, [EMAIL PROTECTED] wrote: Python or C++ On Aug 12, 8:12 pm, Kenton Varda [EMAIL PROTECTED] wrote: In what language? On Tue, Aug 12, 2008 at 12:11 PM, [EMAIL PROTECTED] wrote: Given an object containing a repeated field, is it possible to remove some arbitrary element from that list? --~--~-~--~~~---~--~~ 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 to properly implement RpcChannel::CallMethod
You should send the method's name along with the request. The receiver can
then look up the MethodDescriptor from the service's ServiceDescriptor,
using FindMethodByName().
You might even encode your messages like this:
message RpcRequest {
required string method_name = 1;
// The serialized request message.
required bytes request_data = 2;
}
On Tue, Sep 16, 2008 at 8:54 AM, [EMAIL PROTECTED] wrote:
Hi!
I have some problems setting up a simple IPC system using protocol
buffers for sending the parameters and results between two processes.
I have written a protocol buffers service with a function and a simple
IPC system that can transfer raw byte messages between two processes.
My problem is understanding how my RpcChannel::CallMethod should be
implemented. I was expecting it was as easy to encode the message to
raw bytes and pick it up in the other process and decode it. However,
it turned out that the MethodDescriptor is not encoded in the Message
and it's needed in the other end to route the message to the right
function. I found no functionality to serialize the MethodDescriptor
to a byte stream.
Of course I can come up with encodings for the method descriptor,
either sending the name or the index should work. Then I can just put
it first in the buffer that's transferred to the other process, but
that means I lose the nice feature of letting protocol buffers
handling unicode string encoding, endianness of integers etc. One
approach would be to create a meta message containing both the method
descriptor and the encoded message as a variable size byte array in
one message.
I somehow think I'm missing the point here, how is
RpcChannel::CallMethod supposed to work?
--~--~-~--~~~---~--~~
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: Protocol Buffers can't use in visual studio 2003 ?
I don't think DLLs or LIBs created with a never version of MSVC will work with MSVC 2003. Protobufs use STL heavily in the interface, and I think the STL classes change from version to version. On Tue, Sep 16, 2008 at 4:44 AM, Niall [EMAIL PROTECTED] wrote: I get the same runtime error with MSVC 03. Could some make available the required *.dlls and *.libs which I could download and test with my IDE? This should tell whether it's the dll/ libs that MSVC 2003 makes are the root of the problem or whether it's with program that's linking to them? Right? you can create a new project under the solution of vsprojects, then select the dependencies to lib*, then it will work. I'm not certain what you mean there... Thanks, Niall --~--~-~--~~~---~--~~ 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: Protocol Buffers can't use in visual studio 2003 ?
Even if only the implementation changes -- specifically, the class's memory layout -- that will cause a binary incompatibility, especially since STL is all templates. It seems the debug vs. release versions of MSVC's STL are not even binary compatible, so being compatible between two versions of MSVC seems doubtful. On Tue, Sep 16, 2008 at 10:40 AM, Niall [EMAIL PROTECTED] wrote: Thanks for the reply. You're probably right... but I'm still not convinced it wouldn't work. I couldn't imagine the STL's interface changing. The implementation, sure, but I'd be surprised if the interface would (There'd need to be a real good reason with all that reference paperwork needing changing). Protobufs use STL heavily in the interface, and I think the STL classes change from version to version. Sure, but if I can compile the DLL's and LIB's anyway I can't see this being a problem. This is just gut feeling, though. I can't find anything online to say either way which would happen. Would it be worth trying anyway? If possible. --~--~-~--~~~---~--~~ 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: Protocol Buffers can't use in visual studio 2003 ?
I think you'll have to run it in a debugger and try to figure out the cause of the crash you're seeing. I don't have a copy of MSVC '03, but if you send me the stack trace I could try to guess what's going on. On Tue, Sep 16, 2008 at 1:03 PM, Niall [EMAIL PROTECTED] wrote: Finally. I see what you mean. Thanks for your help and clarification. I wasn't aware of those issues. Thanks again! Any suggestions on how I could use protobufs with MSVC '03? Without the runtime errors when calling SerializeToOstream, that is. Lenjoy, in the second post, said: you can create a new project under the solution of vsprojects, then select the dependencies to lib*, then it will work. But I don't know what that means... I tried a couple of things, like adding a new project to the solution I used in generating the DLLs, libs etc. But with the same result. --~--~-~--~~~---~--~~ 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: Protocol Buffers can't use in visual studio 2003 ?
There are at least two problems with using STL and even ordinary code across DLL boundaries with MSVC, both of which can be hard to get round. One is that if you link statically (select the non-DLL version of the run time libraries) the code inside the DLL will use a different storage pool from code outside the DLL, so store allocated on one side of the boundary and freed on the other side of the boundary will break the storage pool that tries to free it. This will also happen if the run time library selected by the code in the DLL is not identical to that selected by the program using it. Another problem is that much of the STL implementation selected by Microsoft does not use 0 as a special pointer value to mark the ends of linked lists and such things. It tends to allocate a little chunk of memory and use that instead. These marker values are not exported across the DLL boundary, so somebody reading an STL structure created on the other side of the DLL boundary will not recognise the end list marker and will fall of the end and start using rubbish pointers. See http://support.microsoft.com/kb/172396 http://support.microsoft.com/kb/168958 http://www.deez.info/sengelha/2006/03/03/c-stl-dlls-and-buggy-optimizations/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
