[Rprotobuf-yada] strategy for releasing (e.g. what to do about windows)

Romain Francois romain.francois at dbmail.com
Mon Nov 9 15:53:45 CET 2009


On 11/09/2009 01:59 PM, Dirk Eddelbuettel wrote:
>
> On 9 November 2009 at 09:44, Romain François wrote:
> | Hi,
> |
> | I'm getting quite happy about the package now.
> |
> | I plan to integrate Saptarshi's proto file and implement some setAs
> | methods so that we can represent "any" R data as a message, which should
> | be nice.
>
> Ok.
>
> One wishlist item I had was to see if you could please upgrade to Rcpp 0.6.7
> from CRAN, tell me that you've done so ... and I'd then commit my changed
> list_people_R.rcpp that uses RcppList() from Rcpp.

Now requiring Rcpp >= 0.6.7

It does not compile, but I guess this is the part you want to fix:

  -I/usr/local/include    -fpic  -g -O2 -c list_people_R.cpp -o 
list_people_R.o
list_people_R.cpp:14: error: redefinition of ‘class RcppList’
/usr/local/lib/R/library/Rcpp/lib/RcppList.h:40: error: previous 
definition of ‘class RcppList’
make: *** [list_people_R.o] Error 1

> With that, we could change the asList() code to actually use it. And/or
> change other parts to use Rcpp.  Yay or rather Nay?

In the long run, we definitely should use some class encapsulation, 
rather than plain old SEXP stuff.

But right I'm invoking the "it works" excuse, so I'd prefer to write 
unit tests that stress it out, and then refactor so that we know quickly 
what we break.

That's also why I'd like to release before integrating saptarshi's proto 
file

> | But I'd like to release before that, so that people can start to play
> | with it, ...
> |
> | I'm quite uncertain about what to do to release the package so that it
> | works on windows. I'm sure windows people would expect to only have to
> | install the package, so should be distribute a compiled libproto ?
>
> Tricky!
>
> I own several CRAN packages that interface external libs and this issue comes
> up all the time. So far I have never re-packaged the external lib. It would
> help the uninitiated, but it is also somewhat crude.   Plus, I don't really
> like Windows and don't like maintaining build code on that side.  How do you
> feel about that?

I don't like or care about windows, but I want this package to be used ...

We can release saying : right now it only works on unix systems, but 
we'd appreciate help to make a windows binary. Maybe Brian Ripley would 
care to help us, like he does with the XML package IIRC

> | Another thing I'm not sure about is these lines in rprotobuf.cpp :
> |
> | 	MockErrorCollector error_collector ;
> | 	DiskSourceTree source_tree;
> | 	// FIXME : this works only on linux I suppose
> | 	source_tree.MapPath("/", "/");
> | 	Importer importer(&source_tree,&error_collector);
>
> Wow, do we actually walk the entire disk? That sounds crazy!

Of course not. It does not recurse at all, it just replaces the "virtual 
path" with the "physical path", paste with the file name and check if it 
is there.

On the R side, I make sure to pass the full path using 
tools:::file_path_as_absolute so we don't actually need any fancy mapping.

Now that I am a bit more C++ confident, maybe I'll just make my own 
SourceTree implementation instead of using DiskSourceTree

http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.compiler.importer.html#SourceTree

> | which for obvious reasons won't work on windows. This is quite central
> | to the package because if we can't read proto files, we can't do anything.
>
> I think we should respond to an env var RPROTO_TREE_TOP (or some other name)
> and search from there.  Given a dir, we can walk it in either OS.  Doing more
> in a portable manner is an attempt at suicide....

I'd prefer avoiding yet another environment variable.

> | BTW, I was just comparing the byte size of R serialization with the byte
> | size of protobuf's, and it is quite striking:
> |
> |>  message<- new( tutorial.Person, name = "dddd", email = "eeeeeee", id
> | = 1 )
> |>  length( serialize( message, NULL ) )
> | [1] 17
> |>  length( serialize( as.list(message), NULL ) )
> | [1] 166
> |
> | Now I understand what Saptarshi meant with R serialization being verbose.
>
> Nice!
>
> Dirk
>


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



More information about the Rprotobuf-yada mailing list