[Rprotobuf-yada] google protocol buffers

[Romain François]

On 10/27/2009 05:34 PM, Dirk Eddelbuettel wrote:
>
> (Replying to three Romain messages at once)
>
> On 27 October 2009 at 14:53, Romain François wrote:
> | On 10/27/2009 02:20 PM, Dirk Eddelbuettel wrote:
> |>  I don;t think we can do that in C++.
> |
> | No, I had a quick browse a last month and there are a few projects that
> | add reflection capabilities to C++, but apparently this always involves
> | an additional compile step to cook the reflection metadata from the
> | source, so you cannot use it to reflect stuff of not processed classes
>
> Right. IDL solutions like ProtoBuf do that, as does Qt with QOBJECR and the
> MOC layer.  Do you have other pointers for C++ reflection?

Not much more that what you find using a google search. I will not use 
the lmgtfy on you

> |>  Yes but Qt uses the Moc layer and thereby creeates something on top of C++.
> |>  You can't take that 'out of Qt' and into pure C++.
> |
> | That's what I thought. too bad.
>
> I'd be happy to use Qt. The rest of the world may differ ;-)
>
> |>  That may work, and would be cool, but I think it would violate the 'spirit'
> |>  of ProtoBuf as you take it out of protoc.  But one could start it as a proof
> |>  of concept, and then maybe add it into a 'forked' or 'enhanced' protoc.
> |>  Generating R code directly would be __awesome__
> |
> | Right, in that case we should be able to let protoc grab the proto file,
> | but instead of generating classes, generate directly some runtime
> | information.
> |
> | It starts to sound more like a "Duncan Temple Lang" kind of project, but
> | R being the Barack Obama of programming languages I'm sure that the
> | answer will be "yes we can".
>
> ==:-)

I need to squeeze this one in r-help someday. aiming for the fortunes 
package.


> Mail 2:
>
>
> On 27 October 2009 at 15:03, Romain François wrote:
> | One last, and then I do some actual work. I think we'll have to look
> | into the python implementation of the compiler (the thing that takes a
> | proto file and makes the python code from)
> |
> | I'm not much of a python freak, but the code does not seem too
> | difficult. I'm looking at files
> |
> | src/google/protobuf/compiler/python/python_generator.*
> |
> | and I can sort of read the python file that has been generated.
> |
> | There are even hooks to add languages to the command line interface, so
> | that we'll have :
> |
> | protoc file.proto --r-out=tmp
>
> That starts to sound better and better.
>
>
> Mail 3:
>
> On 27 October 2009 at 15:22, Romain François wrote:
> |>  One last, and then I do some actual work. I think we'll have to look
> |>  into the python implementation of the compiler (the thing that takes a
> |>  proto file and makes the python code from)
> |
> | ... and we might not even need to. See this thread.
> | http://groups.google.com/group/protobuf/browse_thread/thread/d0f6d8ad88d2d100#
> |
> | Basically, you can use the --descriptor_set_out= flag in protoc to
> | create a FileDescriptor message that contains (as a protocol buffer) the
> | description of the content of the file.
>
> But doesn't it imply that only Java can read that Description?

I don't think so. Any language that can read the "descriptor.proto" file 
( @ src/google/protobuf of the main tree) should be able to do 
reflective stuff.

> | I've created a mailing list on the r-forge project, which should
> | activate itself in a few days, so that we can structure discussions and
> | leave a trace for the future generations ...
>
> Very good. We should forward some of those there just to keep'em.

I'll repost mine

> Dirk
>


-- 
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