[protobuf] New Google Eclipse-based editor for protocol buffer descriptors
Greetings, I'm proud to announce that today we released a new Eclipse-based editor for protocol buffer descriptors: https://code.google.com/p/protobuf-dt/. Please find the release announcement at the Google Open Source Blog: http://google-opensource.blogspot.com/2011/08/introducing-protobuf-dt-eclipse-editor.html We hope you find this editor useful. Please give it a try and let us know what you think. Regards, -Alex -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/47TDmUqn8ZAJ. To post to this group, send email to protobuf@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] Some great work!
Brilliant. I'm glad to see a protobuf descriptor editor come out of Google. I wrote my own using the XText 1.0 SDK but it was quick and dirty, I like this one much better. There are a few corner cases missing from the syntax however. I know I had a lot of trouble dealing with them using XText because the protobuf grammar has some oddities in it, especially when it comes to enumerations and custom options. The first couple things I noticed when I pulled up the protos I use are: 1) Imports are required to exist in the same directory as the importing proto. Is this intentional? When I used importURI in XText it allowed the files to simply be present in the same project, which allowed for more cleanly managing what proto files are part of the project and which are simply imports. (change in XText 2.0?) 2) Enum Value options are not supported by the current grammar. i.e. ...where the country code type is defined earlier in the same file and evo.name is defined by an import. 3) Custom options that are enumerations are not supported by the current grammar: I need to pull down the project and see if these would be easy to add to the grammar, but I would be glad to contribute to the project as I've been meaning to release my own for some time now and this is a much better starting point. Once I get a better look at the issues and possibly some solutions I'll post them to the project's issue tracker. Thanks for all the hard work - I'm very appreciative and I'm certain the rest of the protobuf community will be as well. -Ben Wright On Tuesday, August 2, 2011 10:26:52 PM UTC-4, Alex Ruiz wrote: Greetings, I'm proud to announce that today we released a new Eclipse-based editor for protocol buffer descriptors: https://code.google.com/p/protobuf-dt/. Please find the release announcement at the Google Open Source Blog: http://google-opensource.blogspot.com/2011/08/introducing-protobuf-dt-eclipse-editor.html We hope you find this editor useful. Please give it a try and let us know what you think. Regards, -Alex On Tuesday, August 2, 2011 10:26:52 PM UTC-4, Alex Ruiz wrote: Greetings, I'm proud to announce that today we released a new Eclipse-based editor for protocol buffer descriptors: https://code.google.com/p/protobuf-dt/. Please find the release announcement at the Google Open Source Blog: http://google-opensource.blogspot.com/2011/08/introducing-protobuf-dt-eclipse-editor.html We hope you find this editor useful. Please give it a try and let us know what you think. Regards, -Alex -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/z_jZIgMzUnoJ. To post to this group, send email to protobuf@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: Some great work!
https://lh3.googleusercontent.com/-M1faNUrY-o0/TjmlMGQdoLI/ADE/NGAzird1rfE/enum%252520value%252520option.png https://lh5.googleusercontent.com/-SvtgqmT8l0A/TjmlJumpWzI/ADA/1OZa-wClt0M/enum%252520value%252520option%252520declaration.png https://lh5.googleusercontent.com/-hXHKu7uh3hI/TjmlF9cYg7I/AC8/0zMzWftDAQ4/custom%252520enum%252520option.png Looks like the images didn't make it in there... they're attached here. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/fhy4A9VFvvUJ. To post to this group, send email to protobuf@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: Some great work!
Alex: Thanks for pointing me to the right place on import paths, next time I'll RTFM ;-) Enum Values are supported, but *Enum Value* *Options *are not... at least as far as i can tell. (I'll have to check more closely tomorrow) As far as supporting custom options goes, I have some experience in that front as I had to support them for what I was doing. They were by far the hardest part to build into the grammar and I never quite got it working right. The best I managed was to have five separate sets of rules, one for each type of custom option (field, enum, enum value, message, file)... I've attached what I came up with for an XText grammar in case it gives you any ideas on how to better handle it. The two things I never quite settled were: 1) How to handle enumation namespaces between enum value declarations and usage of those values in custom options. The namespace in proto is global, but XText grammar expects the ID to be qualified when used in another scope (while the compiler does not)... I suspect I just don't have a good enough grasp of XText to solve that problem. To support enumeration values i ended up putting the enum values at the top level by not having them be part of the the enum production. 2) How to validate the *values *of custom options... I left this as simply either a MessageOption or a DirectOption, where the Message option is constrained to the structure (but not valid contents) of a TextFormat protocol buffer, and the Direct option is any of int, float, ID, etc... This could be taken further to handle each unique syntax type separately but it seems very inelegant and I was hoping to figure out something better before releasing anything (which I won't with now anyway as this is clearly the project that should move forward). One possibility that i was leaning towards that could solve both of these problems was to allow validation of option fields to fall on the compiler itself... The XText API allows for secondary validation to occur, and the compiler provides line and character numbers in it's output... presumably you could just run the exe through java and capture parse the System.out stream to determine any syntax errors not caught directly by the grammar. I did not have the compiler integrated but these plugins do - so it would seem this might not be that difficult to pull in. The downside of this option being that it will not provide auto-complete or other built in features of XText automatically - although to some extent that could be made up for with more custom code. -Ben Wright -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/xApESYTqNVoJ. To post to this group, send email to protobuf@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.xtext Description: Binary data
Re: [protobuf] Re: Some great work!
Hi Ben, I'll take a look at your grammar. Many thanks! I'd suggest to move any conversations regarding the new Eclipse plug-in to its own mailing list: http://groups.google.com/group/protobuf-dt . This way we don't spam non-Eclipse users :) Cheers, -Alex On Wed, Aug 3, 2011 at 4:15 PM, Benjamin Wright compuware...@gmail.com wrote: Alex: Thanks for pointing me to the right place on import paths, next time I'll RTFM ;-) Enum Values are supported, but Enum Value Options are not... at least as far as i can tell. (I'll have to check more closely tomorrow) As far as supporting custom options goes, I have some experience in that front as I had to support them for what I was doing. They were by far the hardest part to build into the grammar and I never quite got it working right. The best I managed was to have five separate sets of rules, one for each type of custom option (field, enum, enum value, message, file)... I've attached what I came up with for an XText grammar in case it gives you any ideas on how to better handle it. The two things I never quite settled were: 1) How to handle enumation namespaces between enum value declarations and usage of those values in custom options. The namespace in proto is global, but XText grammar expects the ID to be qualified when used in another scope (while the compiler does not)... I suspect I just don't have a good enough grasp of XText to solve that problem. To support enumeration values i ended up putting the enum values at the top level by not having them be part of the the enum production. 2) How to validate the values of custom options... I left this as simply either a MessageOption or a DirectOption, where the Message option is constrained to the structure (but not valid contents) of a TextFormat protocol buffer, and the Direct option is any of int, float, ID, etc... This could be taken further to handle each unique syntax type separately but it seems very inelegant and I was hoping to figure out something better before releasing anything (which I won't with now anyway as this is clearly the project that should move forward). One possibility that i was leaning towards that could solve both of these problems was to allow validation of option fields to fall on the compiler itself... The XText API allows for secondary validation to occur, and the compiler provides line and character numbers in it's output... presumably you could just run the exe through java and capture parse the System.out stream to determine any syntax errors not caught directly by the grammar. I did not have the compiler integrated but these plugins do - so it would seem this might not be that difficult to pull in. The downside of this option being that it will not provide auto-complete or other built in features of XText automatically - although to some extent that could be made up for with more custom code. -Ben Wright -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/xApESYTqNVoJ. To post to this group, send email to protobuf@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 protobuf@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.
