Really, it is whatever is enough to show the problem. For example, the
following doesn't (for me) show any issues. You might also want to clarify
your setup - could it be some x64/ia64 related bug, for example? (I'm
testing on x86, Win7):
using System.Collections.Generic;
using
Is it possible, with the plugin framework, to add certain annotations
or even comments (like javadocs) to the .proto file that make it all
the way through to the generated java code?
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to
Hi,
On Tue, Dec 22, 2009 at 06:42, Christopher Piggott cpigg...@gmail.com wrote:
Hmm maybe I can use the UninterpretedOption message to do this.
Would something like this work?
message ChrisMessage {
option javadoc = This is an object representing Chris's Message;
repeated int32 field1 = 1
How about using /// for those special line comments?
This would prevent accidental field comments.
Joern.
On 22.12.2009, at 17:12, Henner Zeller wrote:
Hi,
On Tue, Dec 22, 2009 at 06:42, Christopher Piggott cpigg...@gmail.com wrote:
Hmm maybe I can use the UninterpretedOption message to do
The plugin framework is not meant for this. Plugins can only insert code at
points that have explicitly been declared by the original generator. For
example, in Java, the code generator generates one insertion point in each
class. So, you can add new methods to a message type, but you cannot
Yeah, I agree with it being cluttered if they were handled as
options. I'm still trying to wrap my mind around the plug-ins and
whether or not they are useful to my project.
If the development team would actually consider something to propagate
generated code documentation, one thing to consider
Hi,
Since this question came up earlier today and I have this anyway on my
TODO list, I think this is as well some nice side project for the
holidays I could work on ;)
Basically, there are two forms of comments typically found for
messages and fields: block comments in front of the declaration
I agree, I don't think we should require a specific style for doc comments.
Just take whatever comments appear before / on the same line as the field,
as you describe.
One tricky issue is formatting. Javadoc requires paragraphs to be
explicitly delimited using HTML (p). I've always found this
On Dec 22, 4:53 pm, Henner Zeller henner.zel...@googlemail.com
wrote:
/*
* some block comment
*/
int32 some_field = 1;
int32 some_other_field = 2; // short comment.
I would be fine with that, but I also woudn't have a problem with you
requiring everything be a block, because
Preserving ASCII art sounds great to me, but I'm not sure how this will mesh
with Javadoc. We can't just say Your comments will be interpreted by the
doc tool for the target language because that makes it very hard to write
comments that work nicely in all languages. So for Javadoc we'd
But more difficult is comments like this:
// Blah blah blah here is a list:
// * blah blah blah
// * blah blah blah blah
// * blah blah
Hmm. Javadoc would let you encode lists as ul li ... li ... /
ul which would be nice, though I suppose not critical. Seems that
you could just
On Tue, Dec 22, 2009 at 3:00 PM, Christopher Piggott cpigg...@gmail.comwrote:
Is this a constraint we want to have or need
I think so. I think it's helpful to say This comment is special.
I disagree.
There are two cases:
1) The developer had the doc generator in mind when he wrote the
Hi,
On Tue, Dec 22, 2009 at 15:00, Christopher Piggott cpigg...@gmail.com wrote:
On Dec 22, 4:53 pm, Henner Zeller henner.zel...@googlemail.com
wrote:
/*
* some block comment
*/
int32 some_field = 1;
int32 some_other_field = 2; // short comment.
I would be fine with that,
I am certainly not arguing for HTML -- I am arguing against it.
Something wiki-like would be cool (usually I hate wiki but in this context I
think it makes sense)... but I think that would be too big a dependency for
what we're trying to do. So I think just embedding ASCII art with pre
makes
.. alright, will spend some time tomorrow implementing things.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
If you link protobuf as a DLL:
(1) You must link to the C runtime as a DLL, otherwise you'll end up with
two copies of the C runtime, which may mean two separate heaps, among other
things.
(2) All components of your application which use protocol buffers must link
to the same C runtime as the
On Wed, Dec 23, 2009 at 1:26 AM, Evan Jones ev...@mit.edu wrote:
I've done some quick and dirty benchmarking of Java string encoding/
decoding to/from UTF-8 for an unrelated project, but I've realized
that these performance improvements could be added to protobufs. The
easy way to do UTF-8
On Tue, Dec 22, 2009 at 7:06 PM, David Yu david.yu@gmail.com wrote:
There should be a writeByteArray(int fieldNumber, byte[] value) in
CodedOutputStream so that the cached bytes of strings would
be written directly. The ByteString would not help, it adds more memory
since it creates a
That's a good idea. I'll try that. Thanks.
Mark
On Sun, Dec 13, 2009 at 12:50 PM, Nick Bolton
nick.bolton...@googlemail.com wrote:
Hi Mark,
Comments welcome.
Mark
class ProtocolBufferFileReader:
def __init__(self, input_filename, message_constructor):
self.file =
On Tue, Dec 22, 2009 at 8:18 PM, David Yu david.yu@gmail.com wrote:
On Wed, Dec 23, 2009 at 11:14 AM, Kenton Varda ken...@google.com wrote:
On Tue, Dec 22, 2009 at 7:06 PM, David Yu david.yu@gmail.com wrote:
There should be a writeByteArray(int fieldNumber, byte[] value) in
On Wed, Dec 23, 2009 at 12:21 PM, Kenton Varda ken...@google.com wrote:
On Tue, Dec 22, 2009 at 8:18 PM, David Yu david.yu@gmail.com wrote:
On Wed, Dec 23, 2009 at 11:14 AM, Kenton Varda ken...@google.com wrote:
On Tue, Dec 22, 2009 at 7:06 PM, David Yu david.yu@gmail.comwrote:
21 matches
Mail list logo
