[protobuf] Re: Issue 214 in protobuf: Incorrect generic type parameters in java runtime
Comment #2 on issue 214 by eugene.vigdorchik: Incorrect generic type parameters in java runtime http://code.google.com/p/protobuf/issues/detail?id=214 Sure. Will do it next week when I get home. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@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: What's the right way to bundle Google's code in my project?
Eugene, I am in the exploration process of using Protobuf's with a project. For my level integration I took all the Java Google code and created a Plug-in Project in Eclipse RCP. Then using the export feature (OSGi) I reference the necessary code. I think you might be integrating the Protobuf project in a more low level effort, but this allowed me not to copy and paste any code and provides a clear boundary of the Google code from my own work. Again I suspect we are on fundamentally different efforts but posted to be safe. -Mike On Aug 24, 5:41 pm, Kenton Varda ken...@google.com wrote: On Wed, Aug 18, 2010 at 12:16 AM, Eugene Vigdorchik eugene.vigdorc...@gmail.com wrote: I'm missing the following 3 files and as a result am forced to either copy-paste or duplicate them in my project: google/protobuf/compiler/java/java_helpers.h google/protobuf/stubs/strutil.h google/protobuf/stubs/substitute.h These headers are intentionally not public, as they are not intended to be part of the protobuf library interface. You may, of course, simply copy the code into your project. Ideally we would have some sort of library encapsulating the Java helpers so that you could write a Java code generator plugin without copying all that code, but no one has time to work on this. -- You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group, send email to proto...@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.
Re: [protobuf] Combing multiple messages of only builtin C++ types
If you want to serialize them as one message, make your definition do
exactly that:
message CombinedTypes {
optional int32 int32_val = 1;
optional double double_val = 2;
optional float float_val = 3;
}
Note that you can make the code generator produce effectively the same code
you describe by just defining a wrapper message
message CombinedTypes {
optional Proto_int int_msg = 1;
optional Proto_double double_msg = 2;
optional Proto_float float_msg = 3;
}
When serializing, it does:
1) write tag and type (1, LENGTH_DELIMITED) for Proto_int (e.g., the enum
value you were writing)
2) write length (out-WriteVarint32(int_msg.ByteSize() - you should _not_
use sizeof)
3) write the data
Repeat for double/float. Likewise the generated parsing code will handle
everything for you. The first approach is more efficient though.
On Wed, Aug 25, 2010 at 1:00 AM, bongo bongooban...@gmail.com wrote:
Hi,
I am trying to string up multiple messages of different C++ built-in
types into one message. Conceptually, it's something like:
codedstream int_x float_y double_z;
I am thinking of implementing:
=
.proto File
=
enum Type
{
// Enums that correspond to
// C++ built-in types
Tint = 0;
Tdouble = 0;
Tfloat = 0;
}
Proto_int{ required int val = 1; }
Proto_double { required double val = 1; }
Proto_float { required float val = 1; }
=
C++ code to
write built-in
types to protobuf
=
sos = new StringOutputStream(buf);
out = new CodedOutputStream(sos);
...
// We want to write all 3 of these in ONE protobuf message
double d = 123.0;
int i = 456;
float f = 789.0f;
// Create the messages
Proto_int msg_int;
Proto_doublemsg_double;
Proto_float msg_float;
msg_int.set_val(i);
msg_double.set_val(d);
msg_float.set_val(f);
// Write out the messages:
// 1. First, write out the size of the message ...
out-WriteVarint32(sizeof(msg_int));
// 2. then the type (so that we know how to parse it when we read
back) ...
// QUESTION: WriteVarint32 is used to write ints, what should I use
to
// write double/float?
out-WriteVarint32(Tint);
// 3. then the message itself
msg_int.SerializeToCodedStream(out);
// Then repeat 1 - 3 for double and float, using msg_double/Tdouble
and msg_float/Tfloat respectively.
=
code to READ from
protobuf and reconstruct
built-in types
=
bool read() {
ArrayInputStream ais(static_castconst void *(buf[0]),
buf.size());
CodedInputStream in(ais);
google::protobuf::uint32 type = 0;
google::protobuf::uint32 size = 0;
if (!in.ReadVarint32(size)) return false;
while(size) {
if (!in.ReadVarint32(type)) return false;
CodedInputStream::Limit limit = in.PushLimit(size);
switch(type) {
case Tdouble:
{
Proto_double p;
p.ParseFromCodedStream(in);
}
break;
... similar code for Tint and Tfloat
}
=
Question
=
The above scheme feels very inefficient, and I suspect I am probably
doing it wrong.
For example, do I really need to make dummy wrappers like this:
Proto_int{ required int val = 1; }
What is the correct way to achieve my goal stated above?
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@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 proto...@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.
Re: [scala] [protobuf] [ANN] scala protobuf builder 0.1
I added this to the ThirdPartyAddOns wiki as well. Thanks for contributing
to the protobuf community!
On Thu, Aug 19, 2010 at 3:09 AM, Eugene Vigdorchik
eugene.vigdorc...@gmail.com wrote:
Hi all,
I'm pleased to announce the birth of scala-protobuf project. You can
find the sources at http://code.google.com/p/protobuf-scala .
The goal of the project is allowing easy construction of Google
protobuf (http://code.google.com/p/protobuf/) messages from Scala.
Unlike conventional protobuf code, protobuf-scala allows for a more
code-as-data way to write your protocol messages. Here is a short
example.
Given a protocol definition
message Artist {
required string name = 1;
message Album {
required string title = 1;
repeated string tracks = 2;
optional uint32 year_produced = 3;
}
repeated Album albums = 2;
}
one creates instances like this:
val BradMehldau = Artist (
name(Brad Mehldau),
albums (
Album (
title(Day Is Done),
tracks(
50 ways to leave your lover,
Grenada
),
year_produced(2005)
)
)
)
As most of scalac plugins, protobuf-scala consists of a generator
plugin and a thin runtime layer in scala. The output of scala code
generator requries java classes produced with --java_output, so be
sure to produce it as well.
Hope those of you who use both scala and protobufs find it useful.
Cheers,
Eugene.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.comprotobuf%2bunsubscr...@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 proto...@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.
Re: [protobuf] Enum values are siblings of their type, not children of it.
It could be made an option. Something like...
message MyMessage {
enum Foo {
option cpp_namespace = true;
FIRST = 0;
...
}
...
}
...and then could be made the default if there is ever a Proto3.
But, even if this is just ends up on some if-there-ever-is-a-Proto3
to-do list, that would be cool... just so it's not forgotten about.
It's one of those small things that make the API nicer. I've come
across this scenario several times (and so have other colleagues).
On Tue, Aug 24, 2010 at 5:56 PM, Kenton Varda ken...@google.com wrote:
How would you make this change without updating millions of lines of
existing C++ code that uses protobuf enums?
On Fri, Aug 20, 2010 at 11:12 AM, alopecoid alopec...@gmail.com wrote:
Hi,
This post is about the fact that protobuf enum values use C++ scoping
rules, meaning that, unlike in Java, enum values are siblings of their
type, not children of it.
Say I have the following contrived message:
message MyMessage {
enum Foo {
FIRST = 0;
SECOND = 1;
BOTH = 2;
}
required Foo foo = 1;
enum Bar {
FIRST = 0;
SECOND = 1;
BOTH = 2;
}
required Bar bar = 2;
}
This wouldn't compile because the protobuf compiler recognizes the
fact that for C++, the generated enum values for Foo and Bar would
conflict with each other.
However, for Java, this wouldn't be a problem. I would like to propose
that instead of punishing the generated Java code because of C++'s
strange enum behavior (by forcing developers to rename their enum
values even though they don't collide), that instead, the generated C+
+ enum declarations are wrapped in their own nested namespaces? For
example, something like:
namespace Foo {
enum Enum {
FIRST = 0;
SECOND = 1;
BOTH = 2;
}
}
namespace Bar {
enum Enum {
FIRST = 0;
SECOND = 1;
BOTH = 2;
}
}
At this point, the enum values would be accessed like Foo::FIRST,
Bar::FIRST, etc, which would eliminate the enum value collision
problem altogether, and at the same time make them appear to behave
more like Java's enum scoping rules (which arguably make more sense).
Thoughts?
Thank you.
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@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 proto...@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.
