[Rprotobuf-yada] 3rd party add on approaches

[Romain Francois]

For completeness, added some links.

On 10/27/2009 07:08 PM, Romain Francois wrote:
>
> On 10/27/2009 05:44 PM, Saptarshi Guha wrote:
>>
>> Hello,
>> Top posting here, since something slightly different.
>> I persued 3rd party add ons. Two different approaches exist
>>
>> a) haskell, erlang - they parse the protoc file to write the methods
>> b) c and objc -c : it is a superset of the google protoc source.
>> Build process is altered and the objective c version has extra hooks.
>
> I'm not sure to understand, so I'm not sure what I'm writing here is a
> or b.
>
>   From what I can understand of the code, the code generator (files
> code_generator.cc and code_generator.h is abstract (or whatever is the
> C++ word) with implementations for C++, java and python.

http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.compiler.code_generator.html

> The python implementation looks not so hard, even though I am not a C++
> guy (the language it is written in) or a python guy (the target
> language). Also the generated file for python bindings looks much easier
> to read than the java or c++ file.

http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.compiler.python_generator.html


> Furthermore, the files command_line_interface.* seems to indicate that
> hooks are also present so that one can register another implementation
> language:
>
>     // Register a code generator for a language.
>     //
>     // Parameters:
>     // * flag_name: The command-line flag used to specify an output file of
>     //   this type.  The name must start with a '-'.  If the name is longer
>     //   than one letter, it must start with two '-'s.
>     // * generator: The CodeGenerator which will be called to generate files
>     //   of this type.
>     // * help_text: Text describing this flag in the --help output.
>     //
>     // Some generators accept extra parameters.  You can specify this
> parameter
>     // on the command-line by placing it before the output directory,
> separated
>     // by a colon:
>     //   protoc --foo_out=enable_bar:outdir
>     // The text before the colon is passed to CodeGenerator::Generate()
> as the
>     // "parameter".
>     void RegisterGenerator(const string&  flag_name,
>                            CodeGenerator* generator,
>                            const string&  help_text);
>
>
> so there is hope that we could be able to do something like:
>
> protoc --r_out=somedir somefile.proto
>
> to generate R wrappers. Then we will have to decide what these wrappers
> are. S4 classes could be a good match, but is not notorious for speed ...
>
> This approach relies on writing some R description of the proto to some
> file, than then needs to be sourced into R, etc ... it might be too heavy.
>
>
> Another approach is to rely on the reflection mechanisms that are built
> in the proto lib. When I'll have some time, I'll try to expand on Dirk
> POC so that instead of manipulating a "Person" message, we use a
> "FileDescriptorProto" message, as described in the
> src/google/protobuf/descriptor.proto file.

The parser.h file looks promising for this:

http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.compiler.parser.html


>> The advantage to a) over b) the user would not like so many protoc
>> compilers , the disadvantage to a) is implicility one has to catch up
>> with googles proto
>> language spec( i doubt it will change).
>> However writing a parse for this is not difficult.
>>
>> One approach is generate cpp version of the protoc and then an R
>> function to scan the proto file and generate the R wrappers.
>
> I think it already is C++ code.
>
>>
>> Saptarshi
>
>
>


-- 
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/BcPw : celebrating R commit #50000
|- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc
`- http://tr.im/yw8E : New R package : sos