subject:"\[protobuf\] Re\: protoc plugin compiler extension framework"

[protobuf] Re: protoc plugin compiler extension framework

2010-03-01 Thread phelyks

ok, thanks for pointing me to the right directions and your RPC
system, that should be helpful.

On Feb 27, 12:45 am, Kenton Varda ken...@google.com wrote:
Plugins are now mentioned in the docs in several places:

http://code.google.com/apis/protocolbuffers/docs/reference/other.htmlhttp://code.google.com/apis/protocolbuffers/docs/reference/cpp-genera...
for java-generated and
python-generated)http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google...http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google...

I agree that some sort of tutorial would be nice but my tech writer is on
leave and as an engineer I suck at that sort of thing. :/

Here's a plugin I wrote for my own RPC system:

http://code.google.com/p/capnproto/source/browse/compiler/protoc-gen-...

On Fri, Feb 26, 2010 at 9:00 AM, phelyks felix.schm...@gmail.com wrote:
i think it would also be very helpful to have some sort of dummy-
example-plugin documentation.

at the moment i am completely lost how to begin to write the plugin.

but i dont want to whine: protobufs other documentation is excellent,
so maybe i am just getting too comfortable ;)

On Jan 6, 7:01 pm, Kenton Varda ken...@google.com wrote:
Yes. Sorry, I haven't had a chance to write up formal documentation yet.
See these two files:

http://code.google.com/p/protobuf/source/browse/trunk/src/google/prot
..

On Wed, Jan 6, 2010 at 1:29 AM, Chris hsifdr...@gmail.com wrote:
Is the plugin framework already part of 2.3.0? I can't find any
documentation for this new feature besides some early brainstorming
posts.

On Dec 22 2009, 7:28 pm, Kenton Varda ken...@google.com wrote:
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
stick
javadoc comments on the existing methods.

I think that a system which let you arbitrarily edit the generated
code
would be too fragile -- any change to the code generator would
potentially
break plugins. In fact, I'm even worried that the current system is
risky
because it allows plugins to get access to private members which
could
change, but I don't see any way around that.

All this said, I think it would be great if the protocol compiler
supported
some format for documentation comments and automatically copied those
comments into the generated code. But no one has actually worked on
this
yet.

On Tue, Dec 22, 2009 at 6:42 AM, 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 [javadoc=This is a javadoc for field
1];
repeated int32 field2 = 2 [javadoc=This is a javadoc for field
2];
}

Then write a plug-in that finds those and writes the ones whose
NamePart.equals(javadoc) in as a /** comment */

Possible?

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
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
protobuf%2bunsubscr...@googlegroups.comprotobuf%252bunsubscr...@googlegroups.com

protobuf%2bunsubscr...@googlegroups.comprotobuf%252bunsubscr...@googlegroups.com
protobuf%252bunsubscr...@googlegroups.comprotobuf%25252bunsubscr...@googlegroups.com

.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.

--
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
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@googlegroups.com
protobuf%2bunsubscr...@googlegroups.comprotobuf%252bunsubscr...@googlegroups.com

.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.

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

--
You received this message because you are subscribed to the Google Groups
Protocol

[protobuf] Re: protoc plugin compiler extension framework

2010-02-26 Thread phelyks

i think it would also be very helpful to have some sort of dummy-
example-plugin documentation.

at the moment i am completely lost how to begin to write the plugin.

but i dont want to whine: protobufs other documentation is excellent,
so maybe i am just getting too comfortable ;)

On Jan 6, 7:01 pm, Kenton Varda ken...@google.com wrote:
Yes. Sorry, I haven't had a chance to write up formal documentation yet.
See these two files:

http://code.google.com/p/protobuf/source/browse/trunk/src/google/prot...http://code.google.com/p/protobuf/source/browse/trunk/src/google/prot...

On Dec 22 2009, 7:28 pm, Kenton Varda ken...@google.com wrote:
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
stick
javadoc comments on the existing methods.

I think that a system which let you arbitrarily edit the generated code
would be too fragile -- any change to the code generator would
potentially
break plugins. In fact, I'm even worried that the current system is
risky
because it allows plugins to get access to private members which could
change, but I don't see any way around that.

On Tue, Dec 22, 2009 at 6:42 AM, 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 [javadoc=This is a javadoc for field 1];
repeated int32 field2 = 2 [javadoc=This is a javadoc for field 2];
}

Then write a plug-in that finds those and writes the ones whose
NamePart.equals(javadoc) in as a /** comment */

Possible?

.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.

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

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

Re: [protobuf] Re: protoc plugin compiler extension framework

2010-02-26 Thread Kenton Varda

Plugins are now mentioned in the docs in several places:

http://code.google.com/apis/protocolbuffers/docs/reference/other.html
http://code.google.com/apis/protocolbuffers/docs/reference/cpp-generated.html#plugins(similarly
for java-generated and python-generated)
http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.compiler.plugin.pb.html
http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.compiler.plugin.html

I agree that some sort of tutorial would be nice but my tech writer is on
leave and as an engineer I suck at that sort of thing. :/

Here's a plugin I wrote for my own RPC system:

http://code.google.com/p/capnproto/source/browse/compiler/protoc-gen-capnproto-java.cc

On Fri, Feb 26, 2010 at 9:00 AM, phelyks felix.schm...@gmail.com wrote:

i think it would also be very helpful to have some sort of dummy-
example-plugin documentation.

at the moment i am completely lost how to begin to write the plugin.

but i dont want to whine: protobufs other documentation is excellent,
so maybe i am just getting too comfortable ;)

On Jan 6, 7:01 pm, Kenton Varda ken...@google.com wrote:
Yes. Sorry, I haven't had a chance to write up formal documentation yet.
See these two files:

http://code.google.com/p/protobuf/source/browse/trunk/src/google/prot...http://code.google.com/p/protobuf/source/browse/trunk/src/google/prot.
..

On Tue, Dec 22, 2009 at 6:42 AM, Christopher Piggott
cpigg...@gmail.com
wrote:

Hmm maybe I can use the UninterpretedOption message to do this.
Would something like this work?

Then write a plug-in that finds those and writes the ones whose
NamePart.equals(javadoc) in as a /** comment */

Possible?

protobuf%2bunsubscr...@googlegroups.comprotobuf%252bunsubscr...@googlegroups.com
protobuf%252bunsubscr...@googlegroups.comprotobuf%25252bunsubscr...@googlegroups.com

.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.

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

--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to

[protobuf] Re: protoc plugin compiler extension framework

2010-01-06 Thread Chris

Is the plugin framework already part of 2.3.0? I can't find any
documentation for this new feature besides some early brainstorming
posts.

On Dec 22 2009, 7:28 pm, Kenton Varda ken...@google.com wrote:
 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 stick
 javadoc comments on the existing methods.

 I think that a system which let you arbitrarily edit the generated code
 would be too fragile -- any change to the code generator would potentially
 break plugins.  In fact, I'm even worried that the current system is risky
 because it allows plugins to get access to private members which could
 change, but I don't see any way around that.

 All this said, I think it would be great if the protocol compiler supported
 some format for documentation comments and automatically copied those
 comments into the generated code.  But no one has actually worked on this
 yet.

 On Tue, Dec 22, 2009 at 6:42 AM, Christopher Piggott 
 cpigg...@gmail.comwrote:

  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 [javadoc=This is a javadoc for field 1];
   repeated int32 field2 = 2 [javadoc=This is a javadoc for field 2];
  }

  Then write a plug-in that finds those and writes the ones whose
  NamePart.equals(javadoc) in as a /** comment */

  Possible?

  --

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


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

Re: [protobuf] Re: protoc plugin compiler extension framework

2010-01-06 Thread Kenton Varda

Yes. Sorry, I haven't had a chance to write up formal documentation yet.
See these two files:

http://code.google.com/p/protobuf/source/browse/trunk/src/google/protobuf/compiler/plugin.proto
http://code.google.com/p/protobuf/source/browse/trunk/src/google/protobuf/compiler/plugin.h

On Wed, Jan 6, 2010 at 1:29 AM, Chris hsifdr...@gmail.com wrote:

Is the plugin framework already part of 2.3.0? I can't find any
documentation for this new feature besides some early brainstorming
posts.

On Dec 22 2009, 7:28 pm, Kenton Varda ken...@google.com wrote:
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
stick
javadoc comments on the existing methods.

I think that a system which let you arbitrarily edit the generated code
would be too fragile -- any change to the code generator would
potentially
break plugins. In fact, I'm even worried that the current system is
risky
because it allows plugins to get access to private members which could
change, but I don't see any way around that.

On Tue, Dec 22, 2009 at 6:42 AM, 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 [javadoc=This is a javadoc for field 1];
repeated int32 field2 = 2 [javadoc=This is a javadoc for field 2];
}

Then write a plug-in that finds those and writes the ones whose
NamePart.equals(javadoc) in as a /** comment */

Possible?

.
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en.

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

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 protobuf+unsubscr...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.

Re: [protobuf] Re: protoc plugin compiler extension framework

2009-12-22 Thread Henner Zeller

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 [javadoc=This is a javadoc for field 1];
  repeated int32 field2 = 2 [javadoc=This is a javadoc for field 2];
 }


This javadoc option looks too much of a clutter to me and decreases
the readability of the proto file.

I'd rather have the protoc compiler understand regular JavaDoc like
comments that make it into the meta data - from there the
corresponding language specific comments can be generated.

My suggestion is to support two types of comments. One in front of the
field or message, potentially multiline and starting with
slash-doublestar, much like JavaDoc

  /** This is some field doc
   *  that could potentially span multiple
   *  lines
   */
 repeated int32 field1 = 1;

.. and a end-of-line comment that is on the same line of a field
declaration to save space:

  repeated int32 field2 = 2;  // some field doc describing field in same line.

(this is what is missing from standard JavaDoc and makes field
comments there 100% more space consuming )

Both of these can be unambiguously associated with the corresponding
fields. I have a low prioritized entry on my personal TODO list to add
at some point, but I am happy if someone else wants to work on this ;)

-h

--

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

Re: [protobuf] Re: protoc plugin compiler extension framework

2009-12-22 Thread Joern Huxhorn

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 this.
 Would something like this work?
 
 message ChrisMessage {
 option javadoc = This is an object representing Chris's Message;
 repeated int32 field1 = 1 [javadoc=This is a javadoc for field 1];
 repeated int32 field2 = 2 [javadoc=This is a javadoc for field 2];
 }
 
 
 This javadoc option looks too much of a clutter to me and decreases
 the readability of the proto file.
 
 I'd rather have the protoc compiler understand regular JavaDoc like
 comments that make it into the meta data - from there the
 corresponding language specific comments can be generated.
 
 My suggestion is to support two types of comments. One in front of the
 field or message, potentially multiline and starting with
 slash-doublestar, much like JavaDoc
 
 /** This is some field doc
  *  that could potentially span multiple
  *  lines
  */
 repeated int32 field1 = 1;
 
 .. and a end-of-line comment that is on the same line of a field
 declaration to save space:
 
 repeated int32 field2 = 2;  // some field doc describing field in same line.
 
 (this is what is missing from standard JavaDoc and makes field
 comments there 100% more space consuming )
 
 Both of these can be unambiguously associated with the corresponding
 fields. I have a low prioritized entry on my personal TODO list to add
 at some point, but I am happy if someone else wants to work on this ;)
 
 -h
 
 --
 
 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 
 protobuf+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/protobuf?hl=en.
 
 

--

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

Re: [protobuf] Re: protoc plugin compiler extension framework

2009-12-22 Thread Kenton Varda

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 stick
javadoc comments on the existing methods.

I think that a system which let you arbitrarily edit the generated code
would be too fragile -- any change to the code generator would potentially
break plugins.  In fact, I'm even worried that the current system is risky
because it allows plugins to get access to private members which could
change, but I don't see any way around that.

All this said, I think it would be great if the protocol compiler supported
some format for documentation comments and automatically copied those
comments into the generated code.  But no one has actually worked on this
yet.

On Tue, Dec 22, 2009 at 6:42 AM, Christopher Piggott cpigg...@gmail.comwrote:

 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 [javadoc=This is a javadoc for field 1];
  repeated int32 field2 = 2 [javadoc=This is a javadoc for field 2];
 }

 Then write a plug-in that finds those and writes the ones whose
 NamePart.equals(javadoc) in as a /** comment */

 Possible?

 --

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




--

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

[protobuf] Re: protoc plugin compiler extension framework

2009-12-22 Thread Christopher Piggott

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 for non-java
lanauges is doxygen.  Doxygen comments look a lot like javadoc
comments, and there is support for C, C++, Objective-C, Python,
Fortran, C#, and a bunch of others.

I wouldn't use Doxygen for Java, of course.  (What would be the
point?)

C# is a little tricky, in that Microsoft defines an XML
Documentation language but only gives you Sandcastle (unsupported,
complicated) to do anything useful with them.


On Dec 22, 1:28 pm, Kenton Varda ken...@google.com wrote:
 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 stick
 javadoc comments on the existing methods.

 I think that a system which let you arbitrarily edit the generated code
 would be too fragile -- any change to the code generator would potentially
 break plugins.  In fact, I'm even worried that the current system is risky
 because it allows plugins to get access to private members which could
 change, but I don't see any way around that.

 All this said, I think it would be great if the protocol compiler supported
 some format for documentation comments and automatically copied those
 comments into the generated code.  But no one has actually worked on this
 yet.

 On Tue, Dec 22, 2009 at 6:42 AM, Christopher Piggott 
 cpigg...@gmail.comwrote:

  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 [javadoc=This is a javadoc for field 1];
   repeated int32 field2 = 2 [javadoc=This is a javadoc for field 2];
  }

  Then write a plug-in that finds those and writes the ones whose
  NamePart.equals(javadoc) in as a /** comment */

  Possible?

  --

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

--

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

[protobuf] Re: protoc plugin compiler extension framework

[protobuf] Re: protoc plugin compiler extension framework

Re: [protobuf] Re: protoc plugin compiler extension framework

[protobuf] Re: protoc plugin compiler extension framework

Re: [protobuf] Re: protoc plugin compiler extension framework

Re: [protobuf] Re: protoc plugin compiler extension framework

Re: [protobuf] Re: protoc plugin compiler extension framework

Re: [protobuf] Re: protoc plugin compiler extension framework

[protobuf] Re: protoc plugin compiler extension framework

9 matches

Site Navigation

Mail list logo

Footer information