[protobuf] Re: protoc plugin compiler extension framework
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
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.
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
.
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.
[protobuf] Re: gcc4.4 fixes: std::tr1::unordered_map
The implementation of tr1::hashtable on OSX 1.5 (GCC 4.0.1) is broken. find_node() is apparently not declared const, meaning calling find() on a const hash_map does not compile. /cry On Mon, Dec 21, 2009 at 11:24 AM, Kenton Varda ken...@google.com wrote: Arrghh. I didn't mean to add that... I just wrote it so that I could hit F3 and have eclipse show me the file, then forgot to delete it. Fixed. Thanks for pointing that out; I'm not normally so sloppy. On Mon, Dec 21, 2009 at 11:19 AM, Oleg Smolsky oleg.smol...@gmail.comwrote: BTW, you've added this line to stubs/hash.h #include ext/hash_map but it should not be there. Includes are already handled by these: #include HASH_MAP_H #include HASH_SET_H Oleg. -- 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: gcc4.4 fixes: std::tr1::unordered_map
Worked around with r291. Must test on all platforms all over again... sigh. On Wed, Jan 6, 2010 at 8:29 PM, Kenton Varda ken...@google.com wrote: The implementation of tr1::hashtable on OSX 1.5 (GCC 4.0.1) is broken. find_node() is apparently not declared const, meaning calling find() on a const hash_map does not compile. /cry On Mon, Dec 21, 2009 at 11:24 AM, Kenton Varda ken...@google.com wrote: Arrghh. I didn't mean to add that... I just wrote it so that I could hit F3 and have eclipse show me the file, then forgot to delete it. Fixed. Thanks for pointing that out; I'm not normally so sloppy. On Mon, Dec 21, 2009 at 11:19 AM, Oleg Smolsky oleg.smol...@gmail.comwrote: BTW, you've added this line to stubs/hash.h #include ext/hash_map but it should not be there. Includes are already handled by these: #include HASH_MAP_H #include HASH_SET_H Oleg. -- 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: gcc4.4 fixes: std::tr1::unordered_map
Oh, funky. Sorry, I don't have a Mac to test. Do you have automated builds going? From my experience gcc 4.0.x versions were somewhat buggy, while the 4.1.x branch is reasonable. I am surprised that std::tr1 was actually present in that STL... Perhaps it is an Apple-brewed combo? Oleg. On Wed, Jan 6, 2010 at 8:44 PM, Kenton Varda ken...@google.com wrote: Worked around with r291. Must test on all platforms all over again... sigh. On Wed, Jan 6, 2010 at 8:29 PM, Kenton Varda ken...@google.com wrote: The implementation of tr1::hashtable on OSX 1.5 (GCC 4.0.1) is broken. find_node() is apparently not declared const, meaning calling find() on a const hash_map does not compile. /cry On Mon, Dec 21, 2009 at 11:24 AM, Kenton Varda ken...@google.com wrote: Arrghh. I didn't mean to add that... I just wrote it so that I could hit F3 and have eclipse show me the file, then forgot to delete it. Fixed. Thanks for pointing that out; I'm not normally so sloppy. On Mon, Dec 21, 2009 at 11:19 AM, Oleg Smolsky oleg.smol...@gmail.com wrote: BTW, you've added this line to stubs/hash.h #include ext/hash_map but it should not be there. Includes are already handled by these: #include HASH_MAP_H #include HASH_SET_H Oleg. -- 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: gcc4.4 fixes: std::tr1::unordered_map
On Wed, Jan 6, 2010 at 9:02 PM, Oleg Smolsky oleg.smol...@gmail.com wrote: Oh, funky. Sorry, I don't have a Mac to test. Do you have automated builds going? Only on Linux, unfortunately. Well, and the Solaris one that Monty runs. I suppose I should see about setting up an array of automatic builds on different platforms. From my experience gcc 4.0.x versions were somewhat buggy, while the 4.1.x branch is reasonable. I am surprised that std::tr1 was actually present in that STL... Perhaps it is an Apple-brewed combo? Dunno, but all is good now. I just had to complain about it somewhere. :) Oleg. On Wed, Jan 6, 2010 at 8:44 PM, Kenton Varda ken...@google.com wrote: Worked around with r291. Must test on all platforms all over again... sigh. On Wed, Jan 6, 2010 at 8:29 PM, Kenton Varda ken...@google.com wrote: The implementation of tr1::hashtable on OSX 1.5 (GCC 4.0.1) is broken. find_node() is apparently not declared const, meaning calling find() on a const hash_map does not compile. /cry On Mon, Dec 21, 2009 at 11:24 AM, Kenton Varda ken...@google.com wrote: Arrghh. I didn't mean to add that... I just wrote it so that I could hit F3 and have eclipse show me the file, then forgot to delete it. Fixed. Thanks for pointing that out; I'm not normally so sloppy. On Mon, Dec 21, 2009 at 11:19 AM, Oleg Smolsky oleg.smol...@gmail.com wrote: BTW, you've added this line to stubs/hash.h #include ext/hash_map but it should not be there. Includes are already handled by these: #include HASH_MAP_H #include HASH_SET_H Oleg. -- 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: gcc4.4 fixes: std::tr1::unordered_map
On Wed, Jan 6, 2010 at 9:40 PM, Monty Taylor mord...@inaugust.com wrote: Kenton Varda wrote: On Wed, Jan 6, 2010 at 9:02 PM, Oleg Smolsky oleg.smol...@gmail.com mailto:oleg.smol...@gmail.com wrote: Oh, funky. Sorry, I don't have a Mac to test. Do you have automated builds going? Only on Linux, unfortunately. Well, and the Solaris one that Monty runs. I suppose I should see about setting up an array of automatic builds on different platforms. I'd be happy to set you up a builder on our OSX host if it would be helpful. Thanks, but I'm going to find out if we have infrastructure for this here first. From my experience gcc 4.0.x versions were somewhat buggy, while the 4.1.x branch is reasonable. I am surprised that std::tr1 was actually present in that STL... Perhaps it is an Apple-brewed combo? Dunno, but all is good now. I just had to complain about it somewhere. :) We force gcc-4.2 on OSX in Drizzle for exactly this reason... Does Apple provide a gcc-4.2 for OSX 10.5 (Leopard)? Monty Oleg. On Wed, Jan 6, 2010 at 8:44 PM, Kenton Varda ken...@google.com mailto:ken...@google.com wrote: Worked around with r291. Must test on all platforms all over again sigh. On Wed, Jan 6, 2010 at 8:29 PM, Kenton Varda ken...@google.com mailto:ken...@google.com wrote: The implementation of tr1::hashtable on OSX 1.5 (GCC 4.0.1) is broken. find_node() is apparently not declared const, meaning calling find() on a const hash_map does not compile. /cry On Mon, Dec 21, 2009 at 11:24 AM, Kenton Varda ken...@google.com mailto:ken...@google.com wrote: Arrghh. I didn't mean to add that... I just wrote it so that I could hit F3 and have eclipse show me the file, then forgot to delete it. Fixed. Thanks for pointing that out; I'm not normally so sloppy. On Mon, Dec 21, 2009 at 11:19 AM, Oleg Smolsky oleg.smol...@gmail.com mailto:oleg.smol...@gmail.com wrote: BTW, you've added this line to stubs/hash.h #include ext/hash_map but it should not be there. Includes are already handled by these: #include HASH_MAP_H #include HASH_SET_H Oleg. -- 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] 2.3.0 release candidate #2
I've put up a second release candidate in the same place: https://groups.google.com/group/protobuf/files This one has a bunch of fixes for reported bugs, plus the new support for outputting directly to .zip and (source) .jar files. On Mon, Dec 21, 2009 at 3:00 PM, Kenton Varda ken...@google.com wrote: Hi all, I've uploaded a release candidate of protobuf-2.3.0 here: https://groups.google.com/group/protobuf/files I have tested on Linux (gcc 3.3.6 and 4.2.4), Cygwin, MinGW, MSVC, and OSX (Snow Leopard, latest Xcode). Monty, it would be great if you could test this out on Solaris. Since everything went smoothly, I have some extra time in which I'm going to try to get some new utility classes ported out from our internal repo. My guess is that the final release will have to wait until early January as many people are out of town right now (and I will be soon). -- 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.
