On Oct 29, 2009, at 2:26 AM, Kenton Varda wrote:
> I'm not familiar with R. But, the error means that you've attempted
> to load two different copies of rexp.pb.cc into the same process.
> The protobuf runtime requires that all compiled-in .proto files have
> unique names.
>
> Note that
I'm not familiar with R. But, the error means that you've attempted to load
two different copies of rexp.pb.cc into the same process. The protobuf
runtime requires that all compiled-in .proto files have unique names.
Note that if you have two files with the same name, but in different
directorie
Hello,
I use R 2.9.2 and have written two packages which use a proto file,
one proto is a subset of the other.
When I load both packages(one after the other,though order does not
matter) loading the second causes the following crash
libprotobuf ERROR google/protobuf/descriptor_database.cc:56] Fil
If JSON is an option, how should protoc detect that a plugin wants to use
JSON? We could make it part of the filename, e.g.:
protoc-foo-json (implements --foo_out)
This seems ugly. But, other options I can think of (a config file, some
sort of handshake) would be a lot more complicated.
Hmm,
Kenton Varda wrote:
> Also, writing third-party code generators in languages other than C++ is
> tricky.
Yes, I opted not to bother with .proto parsing for s-protobuf, using
only the protobuf-encoded FileDescriptorSet's that protoc can emit.
> Instead, I propose a similar architecture, but wh
On Wed, Oct 28, 2009 at 4:37 PM, Kenton Varda wrote:
> The code generator should generate exactly the same code regardless of the
> parser version, since newer parsers should never change the behavior of
> existing features.
Yup, I misunderstood that part of your original email. Makes perfect se
On Wed, Oct 28, 2009 at 3:52 PM, Peter Keen wrote:
> This sounds great! Communicating using a well-defined JSON spec sounds
> like a better idea than trying to communicate using protobufs. One
> thing I would suggest is having a protocol version number in there
> somewhere so the generator knows
This sounds great! Communicating using a well-defined JSON spec sounds
like a better idea than trying to communicate using protobufs. One
thing I would suggest is having a protocol version number in there
somewhere so the generator knows what version it's targeting.
--Pete
On Wed, Oct 28, 2009 a
Hi all,
I just had an idea for making protoc more extensible:
Currently, it is possible to write custom code generators and link against
libprotoc to build custom protoc-like binaries. This allows third-party
implementations to reuse the protoc front-end while keeping development
independent. T
It appears that your system lacks strtoll(). You'll need to replace it
somehow. Is your system 64-bit? If so, strtol() should work fine. There's
actually an #ifdef near the top of strutil.h which deals with this for other
systems.
As for the "iter has already been declared" problem, it looks l
I tried to compile protobuf many times on different HP machines with
version 2.1 and 2.2, but all failed. The failure reason is same as
below. Does anybody can gimme some advice ? Thank you in advance!
libtool: compile: aCC -DHAVE_CONFIG_H -I. -I.. -D_REENTRANT -
ansi_for_scope on -mthreads -c
11 matches
Mail list logo
