Hey Petar, isn't there a patch someone was trying to submit that implements
text format parsing? (For real, not by wrapping protoc.) What's the status
of that?
On Mon, Dec 8, 2008 at 5:03 AM, Nicholas Reid <[EMAIL PROTECTED]> wrote:
>
> Hi All,
>
> Firstly, just wanted to thank Kenton and the G
On Sat, Dec 6, 2008 at 1:03 AM, Alek Storm <[EMAIL PROTECTED]> wrote:
> But it does give us a lot of cool functionality, like adding the same
> message to two parents, and (yes!) slicing support. I thought this was
> common practice in C++, but it's been quite a while since I've coded it.
>
Nope
Sorry, there's not a reliable way to do this unless you depend the encoder
writing the tags in order, which is not guaranteed.
One thing you could do is instead of placing an enum field inside your
message to identify the type, stick a one-byte tag on the front of the
message instead. You will hav
Make sure that if your app is compiled in debug mode, you are also using a
debug-mode compile of libprotobuf.lib, and similarly if your app is complied
in release mode you use the release-mode libprotobuf.lib. Unfortunately,
MSVC's STL implementation differs between debug and release mode, and
lib
Unfortunately this would require some pretty big changes to the library,
e.g. to the reflection implementation. Furthermore, the library would end
up depending on boost even for users who don't use this option. So, I don't
think we can do this... Thanks for the idea, though.
On Wed, Dec 10, 200
On Fri, Dec 12, 2008 at 1:20 AM, sorent
wrote:
>
> > Sorry, there's not a reliable way to do this unless you depend the
> encoder
> > writing the tags in order, which is not guaranteed.
>
> Just to make sure I get this right ... (refering to the "Union Types"
> example) if
> I encode a buffer incl
All these questions are hard to answer definitively. It depends on the
details of your use case. In many case there are many possible solutions
and it's impossible to say which one is "best".
One thing that probably matters a lot is the complexity of the queries you
intend to execute on this "dat
pful for developers to
> have access to current and complete documentation - doesn't have to be
> a huge amount, but just something to remind us that it's there.
>
> Thanks,
> Jeff
>
> On Dec 6, 5:48 am, Kenton Varda wrote:
> > protoc
> > * Enum valu
On Tue, Dec 16, 2008 at 2:27 AM, wrote:
>
> Hi,
> I have couple of questions regarding protocol buffers in java
> 1. I am using old bean style data structures. How can i migrate to
> protocol buffers and what problems may arise due to this migration.
This is a pretty broad question with many re
Hmm, I think a better idea would be for the protocol compiler to generate an
enum for each message type which contains all the field numbers. Then you
wouldn't have to define a separate enum in the .proto file.
On Tue, Dec 16, 2008 at 12:53 AM, sorent
wrote:
>
> Hi,
>
> It seems that the proto co
s-0.6c8-py
> 2.5.egg
> Generating google/protobuf/descriptor_pb2.py...
> protoc is not installed nor found in ../src. Please compile it or install
> the b
> inary package.
>
>
> 2008/12/3 Kenton Varda :
> > You need to run setup.py from the directory where it re
Hi Ryan,
What does your code look like that calls SerializeToArray()? It should be
something like:
int size = message.ByteSize();
char* array = new char[size];
message.SerializeToArray(array, size);
On Tue, Dec 16, 2008 at 8:13 PM, Ryan wrote:
>
> I have been working with a Group Communi
OK, I'll stick it on my TODO list. Feel free to send me a patch if you want
it done faster. :)
On Tue, Dec 16, 2008 at 10:53 PM, sorent
wrote:
>
> Definitely a better idea better :-)
> /Sören
> >
>
--~--~-~--~~~---~--~~
You received this message because you are
/protocolbuffers/docs/reference/java/com/google/protobuf/Message.Builder.html
On Tue, Dec 16, 2008 at 10:47 PM, wrote:
>
> Thanks for answer Ketan.
>
> On Dec 17, 12:41 am, Kenton Varda wrote:
> > On Tue, Dec 16, 2008 at 2:27 AM, wrote:
> >
> > > Hi,
> >
s,bplMessage.ByteSize());
>
> //what I am using to detect trailing bytes
>for(int i =0; i< bplMessage.ByteSize();i++) {
>std::cout << (int) mess[i] << std::endl;
> }
>
>
>
> On Dec 17, 8:32 am, Kenton Varda wrote:
> > Hi Ryan,
> > W
same messages always get the
> > erroneous bytes appended. However, if I take one of those messages and
> > send it independently - works fine.
> >
> > Weird...
> >
> > Thanks for the dialog.
> >
> > On Dec 17, 9:36 am, Kenton Varda wrote:
>
On Wed, Dec 17, 2008 at 4:03 PM, Ryan wrote:
> Funny, ParseFromArray gets the right message length when passed a
> buffer 0 padded at the end.
Odd, it should fail (return false) in this case.
>
>
> Thanks
>
> On Dec 17, 12:45 pm, Kenton Varda wrote:
> > When you
Size-wise, the only difference between your "Lite" structure and the current
protobuf classes is that it wouldn't have a virtual table pointer or a
cached byte size. Do these really make that much difference?
On Wed, Dec 17, 2008 at 9:11 PM, Shaun Cox wrote:
>
> As stated by previous posts (the
I can't reproduce this problem. What compiler are you using? Can you
provide example code which demonstrates the problem?
On Mon, Dec 22, 2008 at 2:18 AM, wrote:
>
> Btw, i'm using the latest svn version of the compiler and library
>
> On Dec 20, 11:28 pm, ufukalti...@gmail.com wrote:
> > Hell
I have documented custom options:
http://code.google.com/apis/protocolbuffers/docs/proto.html#options
On Mon, Dec 15, 2008 at 2:55 PM, Kenton Varda wrote:
> Yes, thanks for reminding me. There still isn't any documentation on this
> feature, even inside Google. :( I will try to wr
request,
> Math::Service::MathResponse* response, google::protobuf::Closure*
> done)
> {
>float num1 = request->first();
> float num2 = request->second();
>
>float result = num1 * num2;
>
>response->set_result(result);
>
Email is fine. That's what I use to read this list anyway. :)
On Mon, Dec 22, 2008 at 5:24 PM, wrote:
>
> Is there a way to attach a compressed file here? It would be better if
> i send you a VS solution.
>
> Do you mind if i send you over email?
>
>
> On 23 Aralı
Hmm, works for me. This may sound silly, but try deleting all your
google.com-related cookies. I've seen redirect loops in google services
fixed by this before.
On Fri, Jan 2, 2009 at 9:36 AM, wrote:
>
> Hi!
>
> I tried to access the online doc at
> http://code.google.com/apis/protocolbuffers/
On Thu, Dec 25, 2008 at 6:10 PM, Chris wrote:
> There is a small type on the web page about the custom options:
>
> optional int32 foo = 1 [(my_field_option = 4.5)];
>>
> should be
>
>> optional int32 foo = 1 [(my_field_option) = 4.5];
>>
>
Thanks, I'll fix this.
--~--~-~--~~-
On Sat, Jan 3, 2009 at 7:32 PM, Dave Wolfe wrote:
>
> FYI, it looks like a few new functions are missing __declspec()
> decorators. I had to apply the trivial patch below in order to
> build a DLL version of protobuf under Windows. (This applies to
> both 2.0.3 and the current trunk...)
Ouch,
Yes, I've specifically had that sort of problem with Chrome, and clearing
cookies fixed it in my case. I don't have any other ideas, sorry.
On Mon, Jan 5, 2009 at 12:11 PM, Olivier Gautherot wrote:
> Hi Kenton, thanks for the insight.
>
> On Mon, Jan 5, 2009 at 4:38 PM,
Did the tests pass or fail? The tests explicitly test the code which
produces those warnings, so seeing them is expected. As long as the tests
report that they passed you are fine.
On Mon, Jan 5, 2009 at 12:12 PM, mikesparr...@gmail.com <
mikesparr...@gmail.com> wrote:
>
> Starting a clean inst
these tests.
>
> Mike
>
>
> On Jan 5, 12:19 pm, Kenton Varda wrote:
> > Did the tests pass or fail? The tests explicitly test the code which
> > produces those warnings, so seeing them is expected. As long as the
> tests
> > report that they passed you are fi
for the insight.
> >
> > On Mon, Jan 5, 2009 at 4:38 PM, Kenton Varda > <mailto:ken...@google.com>> wrote:
> >
> > Hmm, works for me. This may sound silly, but try deleting all your
> > google.com-related cookies. I've seen redirect loops in
How would that work, exactly?
On Wed, Jan 7, 2009 at 11:50 AM, mikesparr...@gmail.com <
mikesparr...@gmail.com> wrote:
>
> Is there an existing convert that can take a header file and produce
> a .proto file?
> >
>
--~--~-~--~~~---~--~~
You received this message b
mail.com> wrote:
>
> SWIG is an example of a project that does something in the same vein.
>
> On Jan 7, 1:50 pm, Kenton Varda wrote:
> > How would that work, exactly?
> >
> > On Wed, Jan 7, 2009 at 11:50 AM, mikesparr...@gmail.com <
> >
> > mikes
Protocol buffers are useful even if all users are using the same language.
In fact, we used them in C++ for some time before anyone bothered writing
Java and Python implementations.
On Wed, Jan 7, 2009 at 3:43 PM, Alek Storm wrote:
>
> Mike, what exactly are you trying to accomplish? Do you ju
What do you mean? They aren't for extensions.
On Wed, Jan 7, 2009 at 5:46 PM, Alek Storm wrote:
>
> This seems almost too insignificant to bring up, but why aren't
> kFirstReservedNumber and kLastReservedNumber a
> Descriptor::ExtensionRange?
> >
>
--~--~-~--~~~---~
On Wed, Jan 7, 2009 at 5:39 PM, Alek Storm wrote:
>
> Right, I guess I didn't explain why they don't work in this case.
> Generating .proto files from C++ headers is obviously the reverse of
> the normal sequence. In the PB method of versioning, the
> original .proto is written and deployed. Th
I believe there was a proposal internally that if the caller passes None for
the callback, the RPC implementation should block until completion and then
return the result. Does that seem like what you want?
On Wed, Jan 7, 2009 at 6:23 PM, Alan Kligman wrote:
>
> I poked around a bit and the cod
one too.
>
> a
>
> On Jan 7, 10:02 pm, Kenton Varda wrote:
> > I believe there was a proposal internally that if the caller passes None
> for
> > the callback, the RPC implementation should block until completion and
> then
> > return the result. Does that seem
To give the same answer as Alek with slightly different wording:
The accessors for extensions are analogous to the accessors for a normal
field. For a normal message-type field, there is no "set" accessor. There
is only "mutable". For example:
// Proto
message Foo {
optional Bar bar =
On Fri, Jan 9, 2009 at 12:19 AM, Alek Storm wrote:
> Kenton, do all composite fields in extensions have
> to be optional? If so, can we document this?
Extensions must be optional or repeated, since a required extension doesn't
make sense. I'm pretty sure the compiler checks this. If not, tha
Just to add an official response: Yes, they will be compatible. If they
weren't, we would consider that a very serious bug. Inside Google we have
protobuf data written many years ago that we expect to be able to read with
the latest code. :)
On Sun, Jan 11, 2009 at 8:47 PM, wrote:
>
> Hi,
>
Sorry, you can't use MergeFromCodedStream() like that. The input needs to
be a complete message, which will then be merged into the existing message
object.
On Sun, Jan 11, 2009 at 7:28 PM, chongyc wrote:
>
> I write test code following below.
>
>
>t2r::prot::Request msg0, msg2, msg3, m
Hmm, you're probably right that the arguments should have used hyphens
rather than underscores. That said, we certainly can't just change it
without breaking people, and accepting both seems hacky.
On Mon, Jan 12, 2009 at 10:19 AM, David Biesack wrote:
>
> Has there been any thought to adopting
ibute some code if you like.
>
> On Jan 12, 2:08 pm, Kenton Varda wrote:
> > Hmm, you're probably right that the arguments should have used hyphens
> > rather than underscores. That said, we certainly can't just change it
> > without breaking people, and accepting
Read all the bytes into a buffer, then parse the buffer once you have the
whole thing.
On Mon, Jan 12, 2009 at 4:11 PM, chongyc wrote:
>
> Thank you very much for your help.
>
> I want parsing string 's' by reading each a byte from s.
>
> What is alternative way that you can recommend to me.
>
>
Send the size of the message first, then the data.
On Mon, Jan 12, 2009 at 4:34 PM, chongyc wrote:
>
> When I send multiple messages, I should delimit them, and parse the
> buffer.
>
> What is the best way delimitting it that you can recommend me ?
>
>
>
> On Ja
On Mon, Jan 12, 2009 at 5:27 PM, Alek Storm wrote:
>
> I'm for changing it. Command line flags get deprecated in software
> all the time.
Only for good reasons. This isn't a good enough reason to deprecate. So
the options are between having just the underscore versions or accepting
both unde
On Mon, Jan 12, 2009 at 8:32 PM, Dave Bailey wrote:
>
> I agree, and it seems to be a question that comes up frequently in
> this forum, so maybe we should add a page to the Wiki that discusses
> how to send and receive a stream of protobuf (or any) messages.
I did add some documentation on tha
Sorry, we're trying to get it implemented in Java and Python first. I'm
reviewing the Java implementation today. (Protobuf development can be slow
since no one works on it as their main project...)
On Thu, Jan 15, 2009 at 12:23 PM, Caleb wrote:
>
>
>
> On Dec 3 2008,
On Thu, Jan 15, 2009 at 1:39 PM, Alek Storm wrote:
>
> Just to clarify (because I can't find this addressed anywhere else),
> the length delimeter for repeated fields will be the byte count of the
> whole array, not the count of its elements, right? So an array of 3
> fixed32's would have length
FYI, fixing this is on my todo list... along with a zillion other things...
:/
On Wed, Jan 14, 2009 at 2:15 PM, Paul Carduner wrote:
>
> Hi All,
>
> I am trying to set a dependency on the protobuf package for another
> python package I am developing. Whenever I try to install my python
> packa
Yes, this is true. It's easy to write your own encoding, though. Just look
at the way the TextFormat class is written -- it only uses public
interfaces. So, you could take the TextFormat class and modify it however
you want, or white something entirely different.
On Fri, Jan 16, 2009 at 4:55 PM
[cc Greg to get his attention]
On Tue, Jan 20, 2009 at 9:35 AM, Nat wrote:
>
> So is this going anywhere? Bueller...? Bueller...?
>
> After my last post I was curious to build my first Maven2 plugin, and
> I also now have a working plugin that binds to the generate-sources
> phase like Tom's o
I like to have patches sent using codereview.appspot.com to make it easy for
us to review. Petar (pesho.pet...@gmail.com) is in charge of Python
protobufs so you should send the review to him (and CC me).
On Sat, Jan 17, 2009 at 8:09 AM, Will P wrote:
>
> Hi all,
> I have a speed enhancement pa
Sorry, but we don't allow subclassing of protocol buffer objects (in any
language). Allowing this leads to too many "fragile base class" problems.
If you want to expose all of the fields of your protocol message (which is
what you'd get from subclassing), you can always add an accessor to your
wra
Revision 92:
All Languages
* Repeated fields of primitive types (types other that string, group, and
nested messages) may now use the option [packed = true] to get a more
efficient encoding. In the new encoding, the entire list is written
as a single byte blob using the "length-delimited" w
ot;
> and the last post in this group about it was in August.
>
> many thanks!
> Gregg
>
> On Jul 8, 10:13 am, "Kenton Varda" wrote:
>
> > I have plans to add a new "packed" encoding for repeated fields, which
> would
> > allow there to b
On Thu, Jan 22, 2009 at 1:26 AM, wrote:
> Presumably this is *not* backwardly compatible - i.e. data written
> using a message with the packed encoding can't be read by older
> clients.
It can be ignored by older clients, since it uses an existing wire type.
But adding or removing the packed o
On Thu, Jan 22, 2009 at 12:32 PM, wrote:
> Right. Well, I've ported the new test in TextFormatTest to C# (it
> wasn't exactly hard to port :) but that worked fine. I then made the
> test over 1000 lines long and it still worked, so presumably it's
> okay. I may look at your change anyway - it's n
I think this should do it:
cd src
make libprotobuf.la
On Sat, Jan 24, 2009 at 12:11 PM, Wink wrote:
>
> It is mentioned in this post:
>
> http://groups.google.com/group/protobuf/browse_thread/thread/a0098a395e0ec63c
> That to cross compile you just need build the library.
> What are the tar
The protocol buffer encoding is a binary format. SerializeToString()
actually returns a string containing raw bytes, not text. XML doesn't allow
you to embed raw bytes into it, so you will have to base-64 encode them.
It's probably better to avoid using XML altogether if you can. Embedding a
pr
On Sat, Jan 24, 2009 at 11:24 PM, Sunit Katkar wrote:
> 1) If we use Protocol Buffers, then will it be possible to communicate
> between servers over the HTTP protocol or do we need to write customised
> socket to socket communcation code?
>
Sure. Protocol Buffers simply converts between structu
What version of protocol buffers are you using? I believe we added unicode
support to Python protobufs in 2.0.1 or 2.0.2, in which case you shouldn't
need to manually encode/decode.
On Wed, Jan 28, 2009 at 12:02 AM, bart van deenen
wrote:
>
> Oops found it already :-)
>
> T.s=ustring.encode('utf
Depends on the language, but in general you'd probably have to build a new
message containing all the Persons except the one you no longer want.
On Tue, Jan 27, 2009 at 7:06 PM, Sunit Katkar wrote:
>
> The Address Book example
> http://code.google.com/apis/protocolbuffers/docs/javatutorial.html
>
Petar, can you look into this?
2009/1/29 bart van deenen
>
> Hi Kenton
>
> Here's the details:
>
> kubu:~$ protoc --version
> libprotoc 2.0.3
> kubu:~$ python -V
> Python 2.5.2
>
> This is a self-compiled protoc (because I had added the actionscript
> output generator). I actually find in CHANGE
Gregory, could you please at least check in your code to SVN?
On Mon, Feb 2, 2009 at 8:40 AM, Brian Erst wrote:
>
> Any update on the Maven plug-in? We've had two different plug-ins that
> have essentially been abandoned waiting for an imminent Google release
> for six months now. I've used vari
Tests are not run as part of the build. I think the actual problem is that
the makefile is attempting to invoke protoc to generate some .pb.* files
which are then compiled into the tests (though I think automake builds them
even if you aren't compiling tests because it is too dumb to know). You
s
Was libprotobuf.lib compiled in the same mode (debug vs. release) and with
the same version of MSVC as your project? If not, it could be a binary
compatibility issue between the various versions of the CRT that MSVC uses
in different modes.
Otherwise I don't have any ideas.
On Tue, Feb 3, 2009 a
On Wed, Feb 4, 2009 at 2:17 AM, wrote:
> To begin with I have built the normal c++ protobuf tools (2.0.3 rc2)
Why rc2? That's a release candidate build (like a beta). You should use
the official 2.0.3 release.
> Then I do the same for protobuf-c-0.8
> ./configure --prefix=/usr
> make
> here
Looks cool! I'll have to figure out where to link this...
On Tue, Feb 3, 2009 at 4:17 AM, ptab wrote:
>
> Hello,
>
> I created plugin for Netbeans IDE that supports Protocol Buffers.
> It is there http://code.google.com/p/protobuf-netbeans-plugin/.
>
> Don't hesitate to use, test, report bugs a
The problem is that it's difficult to define what is allowed and what is
not. "Fragile base class" problems are quite diverse. In the end it's up
to you to use your own engineering judgment, but the recommendation from us
is that you look for designs that don't require subclassing protobuf
object
0.8
> and the protobuf-c-0.7 release, all with the same errors as before.
>
>
>
> Any more ideas?
>
>
>
> /Magnus
>
>
> --
>
> *From:* protobuf@googlegroups.com [mailto:proto...@googlegroups.com] *On
> Behalf Of *Kenton Varda
>
Protocol buffers handles byte order automatically. So, you should convert
the number to host byte order and place it in a fixed32 field, then convert
it back to network order on the receiving end. This ensures that the byte
order will come out correctly regardless of the native byte orders of the
Nope, there's no direct support for this in the official protocol buffers
API at present. I think we've generally found that the majority of use
cases don't want event-based parsing (it's harder to work with), but I can
definitely see it being very useful for some cases.
On Fri, Feb 6, 2009 at 2:
Unfortunately I don't think the C++ protobuf implementation is likely to
work very well on a 16-bit platform, since it's not optimized for those kind
of constraints.
Which ints do you need to redefine? If your messages are never more than
32767 bytes then you might get away without changing anythi
Cool, I've added this to the wiki:
http://code.google.com/p/protobuf/wiki/RPCImplementations
On Sun, Feb 8, 2009 at 10:13 PM, Shar wrote:
>
> Hi,
>
> I was looking a simple java socket based client-server implementation
> of protobuf rpcs and couldn't find one so I went ahead an wrote one
> up.
; On Mon, Feb 9, 2009 at 9:39 AM, Kenton Varda wrote:
>
>> Cool, I've added this to the wiki:
>> http://code.google.com/p/protobuf/wiki/RPCImplementations
>>
>> On Sun, Feb 8, 2009 at 10:13 PM, Shar wrote:
>>
>>>
>>> Hi,
>>>
>>
Just the API docs:
http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.io.zero_copy_stream.html
http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.io.zero_copy_stream_impl.html
The ZeroCopyStream interfaces are the underlying abstract stream i
I think the ZeroCopy stuff is a lot less exciting than you seem to imagine.
:)
On Tue, Feb 10, 2009 at 2:50 PM, Yang Zhang wrote:
> Kenton Varda wrote:
>
>> The ZeroCopyStream interfaces are the underlying abstract stream
>> interfaces used by the protocol buffer I/O code. M
Yes. That's the purpose of has_*() -- to tell you if the field was/will be
sent explicitly.
On Wed, Feb 11, 2009 at 3:09 PM, wrote:
>
> From what I have read, it seams that if I don't send an optional
> field, the field will have an explicit or implicit value at the
> receiver. However, will
otnet-protobufs/tree/master
>
>
>
> On Feb 11, 6:34 pm, Kenton Varda wrote:
> > Yes. That's the purpose of has_*() -- to tell you if the field was/will
> be
> > sent explicitly.
> >
> > On Wed, Feb 11, 2009 at 3:09 PM, wrote:
> >
> > &g
Hi Hassan,
The protocol buffers library actually contains a class called DynamicMessage
in C++ and Java which works more like what you describe. There's two
reasons that we prefer the generated classes:
* They are an order of magnitude faster than DynamicMessage. Generated code
can be made *ext
On Mon, Feb 16, 2009 at 5:34 AM, wrote:
> 3. Choose "Regenerate file from this definition"
You didn't specify in your report, but would I be right in guessing that you
are using the NetBeans IDE plugin written by Piotr Tabor? You should
probably contact Piotr directly to report this problem.
There are three C# implementations of Protocol Buffers listed on the wiki:
http://code.google.com/p/protobuf/wiki/OtherLanguages
On Mon, Feb 16, 2009 at 12:51 PM, adeel wrote:
>
> Is there any alternative of protocol buffers in C#.net.
> >
>
--~--~-~--~~~---~--~
I think it's still mostly hypothetical. Any comment, Petar?
On Mon, Feb 16, 2009 at 11:35 AM, Stephan Richter wrote:
>
> Hi everyone,
>
> I started using protocol buffers heavily to communicate between Python and
> Java, but performance is already pretty bad with a few thousand bytes.
>
> In No
Your metadata repository could be defined like this:
// metadata_repository.proto
import "google/protobuf/descriptor.proto"
message MetadataRequest {
repeated string filename = 1;
}
message MetadataReply {
repeated google.protobuf.FileDescriptorProto descriptor = 1;
}
serv
I think this was added in rev 90:
http://code.google.com/p/protobuf/source/detail?r=90
But it hasn't made it into an official release yet.
On Thu, Feb 19, 2009 at 7:12 AM, bart van deenen
wrote:
>
> I'm building a generic gpb editor, that can create gpb encoded files.
> The UI is completely dyna
+petar, who may be able to answer this.
On Wed, Feb 18, 2009 at 6:48 AM, bart van deenen
wrote:
>
> Hi
>
> I'm building a generic editor for creating loading and saving gpb
> objects and am running into problems with dynamic __import__
> statements. I've nailed it down to a very simple testcase.
I don't see an obvious reason why this shouldn't work (other than that your
example code says "toArray" where I think you meant "toByteArray"). Can you
write a small example program demonstrating the problem which I could debug?
On Sat, Feb 21, 2009 at 5:27 PM, Nathaniel wrote:
>
> I'm having a
hout the size).
You should really just stick to using parseFrom(). Is there some reason you
were trying to use CodedInputStream.readMessage() instead?
On Sun, Feb 22, 2009 at 12:40 AM, Kenton Varda wrote:
> I don't see an obvious reason why this shouldn't work (other than that
Not ringing any bells so far. Can you provide a stack trace for the crash?
On Sat, Feb 21, 2009 at 2:56 PM, wrote:
>
> When debugging through the CRT the error starts during the static
> initializer functions
>
> StaticDescriptorInitializer_...
>
> Looks like some access faults but I can't tell
ypack;
>
> message Guy {
> required string name = 1;
> }
>
> message People {
> repeated Guy guy = 1;
> }
> //***
>
> Vista Ultimate / Visual Studio 08 Pro / Static linkage all around (/MTd)
>
> Thanks.
>
&
Hi Tim,
On Mon, Feb 23, 2009 at 7:01 PM, wrote:
>
> In my application, I have a need to track characteristics of message
> fields on a field-by-field basis, e.g. has this field changed. This is
> very much like what is already done in libprotobuf code for tracking
> whether a field has been set
ur system.
> Curious, and Thanks,
> Tim
It's implemented in SVN, and will be in the next release (2.0.4), whenever
that may be. Just stick [packed=true] on to any repeated scalar field:
repeated int32 foo = 1 [packed=true];
>
>
> On Jul 8 2008, 10:13 am, "Kenton
_bit(ATTR1_BIT);
>
> instead of this:
>
> _has_bit(1);
>
> Then my application can use the ATTR1_BIT definitions to implement it
> own tracking of message field characteristics.
>
> Does that change anything?
> Tim
>
> On Feb 23, 7:18 pm, Kenton Varda wrote:
&g
You are correct. Optional fields are not sent if they are not set. This is
documented here:
http://code.google.com/apis/protocolbuffers/docs/encoding.html#optional
On Tue, Feb 24, 2009 at 6:32 AM, Leon Mergen wrote:
>
>
>
> On Feb 24, 2:57 pm, Leon Mergen wrote:
> > After a bit of a search o
>From time to time people suggest protobuf language extensions which involve
evaluating arbitrary expressions. I always push back on this because
expression evaluation would instantly add a lot of complexity to the
language and implementation, and would likely draw in more complexity over
time, an
makefile.in file. I was able to successfully cross-compile the
> google buffers source code to an ARM platform, but I would suggest
> that this should be automated by google in future releases.
>
> On Feb 3, 11:54 am, Kenton Varda wrote:
> > Tests are not run as part of the bu
You may be right, but we've done it that way for many years, and it would be
too hard to change now.
Are there any known STL implementations that use simple null-terminated
strings? string::size() would have to be O(n) for them, which would be
unfortunate.
On Wed, Feb 25, 2009 at 8:30 AM, marc w
Hi Ivan,
I'm pretty torn by this, because there are some people who absolutely insist
that globals should not be cleaned up at shutdown, because it could cause
still-running background threads that are using those objects to crash.
I've argued that those threads should be cleaned up before exiting
Good to know, thanks.
On Wed, Feb 25, 2009 at 2:41 PM, marc wrote:
>
>
>
> On Feb 25, 2:41 pm, Kenton Varda wrote:
> > You may be right, but we've done it that way for many years, and it would
> be
> > too hard to change now.
> > Are there any known ST
/detail?id=4&can=1
>
> -dave
>
> On Feb 25, 3:27 pm, Kenton Varda wrote:
> > Good to know, thanks.
> >
> > On Wed, Feb 25, 2009 at 2:41 PM, marc wrote:
> >
> > > On Feb 25, 2:41 pm, Kenton Varda wrote:
> > > > You may be right, but we
201 - 300 of 1581 matches
Mail list logo
