Re: License changing to BSD.

[Jon Skeet]

(Note: I'm definitely not speaking for Google in this post! Just my
own personal opinions.)

On Sep 25, 10:33 am, Ande Turner [EMAIL PROTECTED] wrote:
 A majority of people are using GPLv3 for newer projects.

For the whole of open source? That sounds unlikely to me. When picking
between different versions of the GPL it sounds more reasonable, but
there's a lot of non-GPL open source software as well.

 Those with GPLv2 can switch to GPLv3 easily in most cases.

 IF it was left as Apache it is GPLv3 compatible anyways.

 Why did you decide against GPLv3?

GPL is much more restrictive than Apache or BSD - I for one would far
rather work on code which could be easily used in commercial products
without forcing the user to open source their code.

Jon

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Re: Status of C# Projects?

[Jon Skeet]

On Oct 6, 3:14 pm, Ben J [EMAIL PROTECTED] wrote:
 Are any of the C# protobuf implementations close to being stable? I
 checked the sites and couldn't really tell (although maybe I missed
 something).

The backing library for my implementation (whatever you want to call
it!) is pretty stable, but the code generator isn't. Or rather, the
code generator as part of protoc is stable at v2.0.1. I'm working on a
code generator implemented in C# itself, which will take the binary
output of protoc and generate C#. That will take a little while to
finish, unfortunately.

I can't remember the status of what's in github, but if you don't mind
the 2.0.1 restriction you could probably use protoc from there for the
moment. You'll need to change your .proto files to use the new
language-specific-option syntax when the new generator's finished, of
course, but that shouldn't be much of an issue.

I'd welcome any testers for my implementation, and could certainly
give help/advice if you run into any issues.

Jon

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Options in 2.0.2 broken?

[Jon Skeet]

It's very possible I'm being silly, but I'm failing to apply options
in 2.0.2. I've updated from svn and built a fresh copy of protoc
(under windows).

Here's the situation:

---options.proto---
import google/protobuf/descriptor.proto;

package extraoptions;

extend google.protobuf.FileOptions {
  optional string NewOption = 2;
}

---test.proto---
import options.proto;

package test;

option (extraoptions.NewOption) = Testing;

message SimpleMessage {
  required int32 x = 1;
}

---Command line---
protoc -otest.pb test.proto

---Results---
test.proto:5:8: Option field (extraoptions.NewOption) is not a field
or extension of message FileOptions.


I've had a look at the source for this error, and it's decorated with
this comment:
// This can only happen if, due to some insane misconfiguration of the
// pools, we find the options message in one pool but the field in
// another. This would probably imply a hefty bug somewhere.

Yikes!

Anyone fancy pointing out my stupid mistake? I haven't tried this on
Linux yet, but I'd be very surprised to find it's a platform-specific
bug.

Jon


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Re: Options in 2.0.2 broken?

[Jon Skeet]

On Oct 10, 9:07 pm, Kenton Varda [EMAIL PROTECTED] wrote:
 Looks like a bug to me.  Thanks for catching it.

No problem. The options stuff looks like it has some interesting
little corners. So far I've run into:

o This one
o A bootstrapping problem: I've tried to apply my options to
descriptor.proto so I can generate the classes. That leads to unknown
fields at descriptor-load time, which goes bang when the merging code
needs to get at a descriptor type :( I've got a workaround, but it's
horrible
o New dependencies on descriptor.proto and csharp_options.proto in
every file I generate from now on - I may need to manually remove the
dependency, but that's horrible too :(
o The NamePart name collision - I'd forgotten that even though
descriptor.proto is optimised for speed, it still generates the field
accessors, so it now needs to take account of the fact that the name
might have a collision...

It's been a long day... but I now have a generator of sorts. I'm
diffing against previous output to see how badly broken it is...

Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Re: Add .net support

[Jon Skeet]

On Oct 23, 12:11 pm, [EMAIL PROTECTED] wrote:
 I am a .net developer  and  I like this protocol buffers , so  I want
 to  extend this to .net framework as well. so  I  need you help.

There are at least 3 projects to support Protocol Buffers in .NET.

See http://code.google.com/p/protobuf/wiki/OtherLanguages

Jon

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Re: C# port has new layout

[Jon Skeet]

On Oct 23, 10:51 pm, Marc Gravell [EMAIL PROTECTED] wrote:
 Plus, with a pre-build protoc, I might be able to do some work on
 protobuf-net code-generation (I never did get VS working with the
 official version...).

Cool. We should get together some time and see whether we can't pool
our efforts to some extent. I've been talking to Cyrus Najmabadi about
some other possibilities for dynamic code generation too - I don't
know whether it would be better to have these all as separate
projects, or maybe separate assemblies relying on the same core.
Separate projects gives more room for experimentation, of course. I
think I need to take a closer look at your implementation first
though :)

Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Re: Status of C# Projects?

[Jon Skeet]

On Oct 28, 12:04 am, honce [EMAIL PROTECTED] wrote:
 We are looking at the dotnet-protobufs for a new and are unable to
 build the generated C# code. I downloaded the latest code out of git
 and have been successful in building a C# file.

 We have been running:
 protoc -operson.bin person.proto
 protogen person.bin

 We add person.cs to our solution and rebuild with VS2008sp1 targeted
 for .Net 3.5sp1 on WinXP sp3. We then get the following error:
 Person.cs(7,29): error CS0441: 'Person': a class cannot be both static
 and sealed

Odd. It certainly sounds like a straight bug, but I'm amazed that I
haven't seen it elsewhere.

Do you not specify a package or namespace anywhere? That may be
relevant (although it's still a bug in protogen, of course).
Look at the unit tests for examples of how to specify things - I'm
hoping to make it simpler in terms of the csharp_options.proto and
descriptor.proto dependencies over time.

Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Re: Status of C# Projects?

[Jon Skeet]

On Oct 28, 12:04 am, honce [EMAIL PROTECTED] wrote:
 We are looking at the dotnet-protobufs for a new and are unable to
 build the generated C# code. I downloaded the latest code out of git
 and have been successful in building a C# file.

 We have been running:
 protoc -operson.bin person.proto
 protogen person.bin

 We add person.cs to our solution and rebuild with VS2008sp1 targeted
 for .Net 3.5sp1 on WinXP sp3. We then get the following error:
 Person.cs(7,29): error CS0441: 'Person': a class cannot be both static
 and sealed

 Any suggestions on what we're doing wrong?

Got it - the problem here is that it's generating a Person type as the
umbrella class, and also Person as the message.

You could either specify the name of the umbrella class as an option,
or just rename person.proto to (say) person_protofile.proto. It would
then create PersonProtoFile.cs with a PersonProtoFile umbrella class,
and a Person class for the Person message. The resulting file
definitely does compile :)

I'll try to remember to add a check for that situation - I suspect I
won't be able to catch everything like that, but I'll do what I can.

Jon



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Adding options without adding dependencies

[Jon Skeet]

I've been using the new options features to add options for C# code
generation - similar to the existing Java options.

Two issues have arisen:
1) (Fairly simple to resolve, probably) - I think it would be worth
creating a repository of known extensions for descriptor.proto. For
instance, here's my csharp_options.proto:

import google/protobuf/descriptor.proto;

package google.protobuf;

option (CSharpNamespace) = Google.ProtocolBuffers.DescriptorProtos;
option (CSharpUmbrellaClassname) = CSharpOptions;

extend FileOptions {
  optional string CSharpNamespace = 2;
  optional string CSharpUmbrellaClassname = 20001;
  optional bool CSharpMultipleFiles = 20002;
  optional bool CSharpNestClasses = 20003;
  optional bool CSharpPublicClasses = 20004;
}

It would be nice if no-one else used 20,000-20,099 (to allow room to
grow). That way different options would be interoperable.

2) (More important.) There's no real reason why anything other than C#
protogen needs to understand these extensions - it would be really
nice if protoc could avoid adding dependencies from the business
proto file to descriptor.proto and csharp_options.proto. ProtoGen will
load the descriptor set with the relevant extension registry anyway -
there's no need to actually mention it in the dependency list.

How reasonable would it be to have certain dependencies ignored on
output (i.e. removed from the descriptor set
FileDescriptorProto.dependency list.)

For instance, instead of:

import google/protobuf/descriptor.proto;
import google/protobuf/csharp_options.proto;

messages could have:

import transient google/protobuf/descriptor.proto;
import transient google/protobuf/csharp_options.proto;

I suspect we'd have to make sure (somehow!) that the dependencies were
only used for extensions but it would solve a definite pain point.

Any thoughts?

Jon


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Re: adding languages to protoc

[Jon Skeet]

On Oct 30, 7:55 pm, Marc Gravell [EMAIL PROTECTED] wrote:
 Actually, for the protobuf-net code-generator, I've gone down a
 different route. I load the binary descriptor, and then serialize it
 to xml. I then run this xml through an xslt transformation, and voila!
 code. This has a couple of nice features:

snip

It would be interesting to see how easy it would be to have a parallel
transformation to generate C# suitable for my port as well... I can
certainly see there'd be plenty of advantages over the hand-coding
I've currently got. There's a certain amount of actual logic involved
though.

Marc: we really, really need to get together again some time to thrash
through some ideas...

Jon

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Re: Streaming

[Jon Skeet]

On Dec 4, 10:00 pm, Shane Green [EMAIL PROTECTED] wrote:
 Would the following two methods enable streaming of protocol buffer
 messages:

 SerializeToBuffer(buffer) - which writes the serialized message to the
 stream, plus a single field whose wire-type is 4 (End Group).

 ParseFromBuffer(buffer) - which parses data read from the buffer until
 it reaches a standalone field of wire type 4.  This field would be read
 from the buffer and then discarded before returning.

Rather than parse until a particular tag, it's simpler to serialize an
object as if it were a repeated field of a container object.

That way, apart from anything else, if you ever *do* write the
container object, everything is already compatible.

This is what I've done in my C# port (always using field number 1,
although I may provide a way of writing/expecting a different field at
some point) and it works well.

Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Re: 2.0.3 officially released

[Jon Skeet]

On Dec 5, 6:48 pm, Kenton Varda [EMAIL PROTECTED] wrote:
 http://code.google.com/p/protobuf/downloads/list
 Hopefully less buggy than last time.  :)

Congrats :)

   protoc

   * Fixed bug where .proto files which use custom options but don't actually
     define them (i.e. they import another .proto file defining the options)
     had to explicitly import descriptor.proto.

Excellent. This should make it easier for users of my project. I'll
update some time next week, hopefully.

I'd still like some way of marking either an import or a .proto file
itself as don't add as a dependency. The option support is a bit
unwieldy at the moment in terms of dependencies - if someone wants to
generate code for languages A, B and C, language A doesn't care about
the options for B and C, etc. Given that they're just options, they
can end up as uninterpreted options for languages which don't need
them - the relevant language would just need to explicitly register
their own extensions to pick up their options.

Does that make any sense? I feel I'm not explaining it terribly well.
This would have to be a change to protoc unfortunately as that's what
generates the list of dependencies.

   Java
   * New overload of mergeFrom() which parses a slice of a byte array instead
     of the whole thing.

Ooh. I guess I need to port that over to the C# at some point...

Jon


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Re: how to parse a file with millions of records with protobuf

[Jon Skeet]

On Dec 7, 11:45 am, nightwalker leo [EMAIL PROTECTED] wrote:
 when I try to parse an addressbook file which has 2^20 records of
 person , my program complains like this:
 libprotobuf WARNING D:\protobuf-2.0.2\src\google\protobuf\io
 \coded_stream.cc:459] Reading dangerously large protocol message.  If
 the message turns out to be larger than 67108864 bytes, parsing will
 be halted for security reasons.  To increase the limit (or to disable
 these warnings), see CodedInputStream::SetTotalBytesLimit() in google/
 protobuf/io/coded_stream.h.

 how to deal with the problem in an elegant way instead of increasing
 the limit or simply turning off the warning message?

In my C# port, I have code to write out messages as if they were a
repeated field #1 of a container type, and another class to read in
the same format in a stream manner, one entry at a time.

Would that useful to you?

Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Re: State of protobuf for C# ?

[Jon Skeet]

On Dec 17, 10:59 pm, michael-l...@gmx.net wrote:
 I know of the different protobuf implementations for .NET. How is the
 state of these projects ? I would actually tend to Jon Skeets
 implementation because he's an official project member and Google
 employee. Is there some V1 to be expected in the near future ?

I should point out that although I'm certainly a Google employee, I
only joined in April and haven't used Protocol Buffers very much
within my daily work. My experience of Marc's code (in general, not
just this project) is that it's rock solid.

My project is pretty stable now, although I could do with putting some
work into making the generation easier and more flexible. (I also need
to upgrade to 2.0.3 for protoc.)

I need to write some positioning some time, but basically if you're
*only* using .NET - and particularly if you're also using WCF etc -
then Marc's is probably the best bet. If you want consistency between
C# code and Java/C++ code, mine is likely to be more appropriate.
They're all compatible in terms of the data, of course.

Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Additional testing file

[Jon Skeet]

On Jan 6, 3:11 pm, Chris turingt...@gmail.com wrote:
 I found the attached protobuffer file quite useful in torture testing
 the ability to handle circular dependencies.

Great, thanks - I'll try it against my C# port as soon as I can.

Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Additional testing file

[Jon Skeet]

On Jan 6, 3:11 pm, Chris turingt...@gmail.com wrote:
 Perhaps the attached file is a useful addition to the protocol-buffers
 test suite — perhaps not for the core languages but it will serve as a
 concrete problem case for the other language generators to solve.

snip

Just to make it absolutely explicit - are you happy for the proto file
to be included in other open source Protocol Buffer implementations?
In particular, I'd like to include it in my C# port, under the New BSD
licence (http://www.opensource.org/licenses/bsd-license.php)

Please confirm that this is okay, so I can add it to my git/svn
repositories without concerns :)

Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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
-~--~~~~--~~--~--~---

Initial benchmarking committed to svn (r100)

[Jon Skeet]

I've just committed the first pass of a benchmarking tool to trunk.
Everything is under benchmarks - see the readme.txt for usage
guidelines.

I have a bit of tidying up to do before the committed C# version is
*exactly* equivalent (I've changed my build file around a bit) but
I've got some initial results. There are two .proto files,
representing the same messages (Message1 and Message2) but with one
optimized for speed and the other for size. (This is a great case
where a command-line option to override the optimization flag would be
handy :) There are two data files, one for each message. The benchmark
results below are running each version with each message file, with
the Java code and my current C# code.

I haven't optimised with a profiler very recently - I suspect there
are some improvements which could be made by skipping the null
handling when merging/parsing (as it should be unnecessary). I didn't
use any particular options when running the Java version (1.6.0_11-
b03) so I'm sure there are tweaks to be made there too.

Java:
Benchmarking benchmarks.GoogleSize$SizeMessage1 with file ../
google_message1.dat
Serialize to byte string: 1077894 iterations in 30.03s; 7.80469MB/s
Serialize to byte array: 1044398 iterations in 28.86s; 7.86873MB/s
Serialize to memory stream: 981322 iterations in 30.172s; 7.0720015MB/
s
Deserialize from byte string: 1378737 iterations in 30.048s;
9.977018MB/s
Deserialize from byte array: 1374400 iterations in 30.581s; 9.772291MB/
s
Deserialize from memory stream: 1212133 iterations in 30.478s;
8.647663MB/s

Benchmarking benchmarks.GoogleSpeed$SpeedMessage1 with file ../
google_message1.dat
Serialize to byte string: 8876207 iterations in 30.358s; 63.575417MB/s
Serialize to byte array: 8977534 iterations in 30.044s; 64.9732MB/s
Serialize to memory stream: 5715348 iterations in 30.485s; 40.765373MB/
s
Deserialize from byte string: 9295886 iterations in 30.159s;
67.020676MB/s
Deserialize from byte array: 9003228 iterations in 29.266s; 66.89133MB/
s
Deserialize from memory stream: 5888670 iterations in 30.466s;
42.027805MB/s

Benchmarking benchmarks.GoogleSize$SizeMessage2 with file ../
google_message2.dat
Serialize to byte string: 2598 iterations in 29.922s; 7.002691MB/s
Serialize to byte array: 2602 iterations in 30.545s; 6.8704243MB/s
Serialize to memory stream: 2412 iterations in 30.257s; 6.429362MB/s
Deserialize from byte string: 1831 iterations in 30.37s; 4.8625035MB/s
Deserialize from byte array: 1853 iterations in 30.383s; 4.918823MB/s
Deserialize from memory stream: 1839 iterations in 30.754s;
4.8227696MB/s

Benchmarking benchmarks.GoogleSpeed$SpeedMessage2 with file ../
google_message2.dat
Serialize to byte string: 18033 iterations in 30.088s; 48.33827MB/s
Serialize to byte array: 17808 iterations in 30.264s; 47.457542MB/s
Serialize to memory stream: 16569 iterations in 30.037s; 44.48936MB/s
Deserialize from byte string: 13837 iterations in 29.609s; 37.690735MB/
s
Deserialize from byte array: 14163 iterations in 30.208s; 37.813744MB/
s
Deserialize from memory stream: 12945 iterations in 28.333s;
36.84902MB/s


C#:
Benchmarking
Google.ProtocolBuffers.ProtoBench.SizeMessage1,BenchmarkTypes with
file google_message1.dat
Serialize to byte string: 1929013 iterations in 30.191s; 13.893MB/s
Serialize to byte array: 1939375 iterations in 30.179s; 13.973MB/s
Serialize to memory stream: 1759325 iterations in 29.956s; 12.770MB/s
Deserialize from byte string: 1876302 iterations in 28.483s; 14.323MB/
s
Deserialize from byte array: 1995484 iterations in 30.554s; 14.201MB/s
Deserialize from memory stream: 1831091 iterations in 30.731s;
12.956MB/s

Benchmarking
Google.ProtocolBuffers.ProtoBench.SpeedMessage1,BenchmarkTypes with
file google_message1.dat
Serialize to byte string: 17117282 iterations in 30.787s; 120.893MB/s
Serialize to byte array: 17551170 iterations in 30.469s; 125.251MB/s
Serialize to memory stream: 10226358 iterations in 28.105s; 79.117MB/s
Deserialize from byte string: 12752420 iterations in 29.695s; 93.379MB/
s
Deserialize from byte array: 12713411 iterations in 29.833s; 92.661MB/
s
Deserialize from memory stream: 8628148 iterations in 39.201s;
47.859MB/s

Benchmarking
Google.ProtocolBuffers.ProtoBench.SizeMessage2,BenchmarkTypes with
file google_message2.dat
Serialize to byte string: 4735 iterations in 29.045s; 13.148MB/s
Serialize to byte array: 4873 iterations in 30.436s; 12.913MB/s
Serialize to memory stream: 4417 iterations in 30.081s; 11.843MB/s
Deserialize from byte string: 3119 iterations in 30.270s; 8.310MB/s
Deserialize from byte array: 3123 iterations in 30.153s; 8.353MB/s
Deserialize from memory stream: 3088 iterations in 30.299s; 8.220MB/s

Benchmarking
Google.ProtocolBuffers.ProtoBench.SpeedMessage2,BenchmarkTypes with
file google_message2.dat
Serialize to byte string: 32605 iterations in 30.184s; 87.122MB/s
Serialize to byte array: 32445 iterations in 30.360s; 86.191MB/s
Serialize to memory stream: 19121 iterations in 30.093s; 51.245MB/s

C# port status update

[Jon Skeet]

Just a quick update on the C# port of the Java code (at
http://code.google.com/p/protobuf-csharp-port/)

I've just done a bit of work to get the C# code in line with the 2.1
release, with the exception of the RPC changes (which I need to take a
closer look at). There are a number of things I'd like to look at, and
I'd appreciate a little community guidance in terms of what others
would really like to see. Things I've been thinking about:

- Improving the benchmarking framework to allow benchmarking scripts
(work already in progress)
- Implementing a DLR dynamic message builder (which I'll probably do
anyway as it'll be a useful example for the 2nd edition of my C#
book :)
- Getting it all to build and run on Mono 2.4 (Windows and Linux? Just
Linux?)
- Adding a feature to protoc to allow .proto files to express imports
which shouldn't produce dependencies (so that you can use the C#
options without it affecting generation of C++/Java code)
- Using protoc with P/Invoke from protogen so that code generation is
a one-step process
- More/better documentation (including polishing the XML documentation
in the code itself)
- Binary distributions
- Assembly versioning
- Considering moving the code into the Google distribution (as
requested in http://code.google.com/p/protobuf/issues/detail?id=102)

At the moment Protocol Buffers are more spare time work than 20%
time work due to new 20% projects, and I'd like to use my time as
effectively as possible - so if anyone would like to offer any
thoughts on how I might prioritise this (or any other features) I'd
really appreciate it.

Jon

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Python C Implementation - Update Request

[Jon Skeet]

On Jun 2, 11:56 pm, Jon Skeet sk...@pobox.com sk...@pobox.com
wrote:
 One positive thing to note is that if I can get the dynamic stuff
 working with the C# port (when I've got custom options to actually
 work: there's a whole bunch of changes I missed before) it should be
 usable from IronPython. I know that .NET 4.0 and IronPython will only
 be useful to a subset of our Python customers but it may be faster
 than a pure Python implementation. (I'd be interested to see.)

Marc pointed out to me that of course any of the .NET implementations
should be usable from IronPython anyway. Note to self: don't post when
tired.

Jon

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: C# port status update

[Jon Skeet]

On Jun 7, 2:24 pm, ualtinok ufukalti...@gmail.com wrote:

snip

 Although those modifications had worked for me (at least just for my
 trials), it's not solid.

Solid in what sense? Do you run into problems, or you're just not
confident in them?

 Can you tell me what you will need in the sample project? A full test
 suite or just some serialize and deserialize?

A very small sample Silverlight project I can load up in Visual Studio
and debug into, which tries to serialize and deserialize in the way
that you'd expect to in your real code.

I think the normal test suite should cover most of the changes (and
now you've reminded me I'll try to push the simpler ones into source
control) but I'm concerned that even when I get it to compile, I could
do with actually running things under Silverlight - and not having any
experience of that, a sample project will probably help.

Jon

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Suggestion for improving WriteDelimited/ParseDelimited

[Jon Skeet]

On Jun 9, 8:28 pm, Kenton Varda ken...@google.com wrote:
 I still think that this doesn't belong in the scope of protocol buffers, but
 rather some higher-level utility library.

Doesn't that make writeDelimited/parseDelimited somewhat less useful
then? You can write as many messages as you like to a file, but you
don't know when you've finished reading them...

I can see the argument for keeping these things in a higher-level
utility library, but we've done *half* the job in PBs now (without
giving enough information to finish the job elegantly).

 That said, what does your proposal offer over the
 writeDelimited/parseDelimited methods added to the Java runtime in 2.1.0?
  (Still need to add them to C++ and Python...)

I'm talking about making exactly those methods more useful.
Ironically, my C# port already has a separate way of writing a
message stream and iterating over it, based on a previous discussion
- basically we write individual messages as if they were repeated
fields of some container message. (Pleasantly, if you then define such
a container message, you can just read a file written by
MessageStreamWriter as an instance of that container.) In that case, I
just call readTag until it returns 0... but there's no equivalent for
writeDelimited/parseDelimited. ParseDelimited will either return a
newly built message, or throw an exception if it encounters bad data
or the end of the file. In particular, there's no way of telling the
difference between a file that finished correctly at the end of a
message and a file that contains half a message (or half a message
*size*) at the end.

To put it another way: if you don't know how many messages have been
written to a file, how would you propose reading them with the current
API? I suppose you could wrap the stream in a PushBackInputStream, and
between each message read the next byte and either finish if you
detect the end of the stream, or push the byte back and read another
message otherwise. I'd like to think we can do better than that
though :)

Jon

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: speed option for code generation

[Jon Skeet]

On Jun 9, 8:31 pm, Kenton Varda ken...@google.com wrote:
  Is the plan that the reflection parts of the API will just throw
  exceptions, or will there be non-reflection interfaces which are
  implemented by these generated classes?

 There will be a new interface called MessageLite which is a superclass of
 Message.  (Just making the reflection methods throw exceptions wouldn't
 really work because just their type signatures would imply dependencies on
 the reflection classes.)

Great. I can see this being useful in the Compact Framework, too. I
think part of the reason Marc's currently reimplementing his .NET port
is due to some constraints on delegates in the Compact Framework -
without requiring the reflection API, I suspect the lite C# port
will be able to avoid some of these problems. (I may well need to
split the project into a non-reflection core and then a reflection-
enabled layer built on top of it though.)

Admittedly the extra interfaces could end up being interesting when
it comes to C# - it's already pretty hairy :)

Jon

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Suggestion for improving WriteDelimited/ParseDelimited

[Jon Skeet]

On Jun 10, 12:01 am, Kenton Varda ken...@google.com wrote:
 Ah, I see.  How about if we just extend parseDelimited() to return null at
 EOF?

Absolutely - the problem is that I *suspect* that means the
mergeFromDelimited method will need to break the normal builder
convention of returning itself, unless it returns itself or null.
Given that the primary user of this is going to be parseDelimited, I
suspect that changing it to return a boolean would be simpler. It's an
unfortunate aspect of the builder pattern that there's no simple way
of stopping it half way through :(

Sorry for not being clear in my first message - glad we're on the same
page now :)

Jon

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: ANN: protobut-net with VS2008 support

[Jon Skeet]

On Jul 16, 10:02 am, Marc Gravell marc.grav...@gmail.com wrote:
 I'm happy to say that protobuf-net now features VS2008 integration.
 Please see the following page for more 
 information:http://marcgravell.blogspot.com/2009/07/protobuf-net-now-with-added-o...

Nice work - makes my port look somewhat hard work :) If I can ever
call the native protoc library using P/Invoke, I could at least make
ProtoGen a one-shot option... that's still a fair way from that level
of integration though.

Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Lite mode is in SVN -- mostly

[Jon Skeet]

On Jul 29, 3:50 am, Kenton Varda ken...@google.com wrote:
 I just committed the new lite mode refactoring for C++ and Java to SVN.
 To use the new feature, add this line to your .proto file:
   option optimize_for = LITE_RUNTIME;
 This will cause protoc to generate code which is just as fast as with
 optimize_for = SPEED, but lacks descriptors, reflection, UnknownFieldSet,
 and features which are tied to them.  This means the code can be linked
 against a much smaller subset of the protocol buffers runtime library and
 will not spend time at start-up building descriptors.

Just in case anyone's wondering, I'm hoping to at least *start* work
on porting this to C# early next week. (I have two days dedicated to
20% time next week, but I also want to do some Wave work.)

Out of interest Kenton, does this make the bootstrapping code simpler?
I'd imagine that can be built with just a lite version. It would be
nice to get rid of some of the nastiness that's involved in C# just to
get the PB-specific types to work :)

Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Can't seem to make Extension parsing working...

[Jon Skeet]

Have you tried using the overload of parseFrom which takes an
extension registry?

Make sure you register all the extensions first, of course - call the
appropriate registerAllExtensions static method, passing in the
extension registry, before calling parseFrom(src.toByteArray(),
registry).

Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Can serialized messages be used reliably as keys?

[Jon Skeet]

On Sep 29, 8:22 pm, alopecoid alopec...@gmail.com wrote:
 Can serialized messages be used reliably as keys?

 In other words, is it guaranteed that...

 - Two equal messages will always generate equal byte sequences?
 (Are fields always written in the same order?)

 - Two unequal messages will always generate unequal byte sequences?
 (Are tag identifiers enough to delimit variable length fields from
 accidentally producing equal byte sequences?)

 I have a feeling that the answer is no. For example, given a proto
 with two fields, both variable length int64 types, it seems that two
 unequal messages could, by chance, generate the same byte sequence:

 [1 byte tag] [3 byte value] [1 byte tag] [2 byte value] = 7 bytes
 [1 byte tag] [2 byte value] [1 byte tag] [3 byte value] = 7 bytes
 [1 byte tag] [6 byte value] = 7 bytes
 ... etc.

 If those 7 bytes just happen to be equal, then the serialized messages
 can NOT be used reliably as keys.

Given that the serialized bytes have to be able to *deserialize* back
to the original messages, surely if those original messages aren't
equal, the serialized forms would have to be different too - assuming
we're talking about the same message type. (Two messages of different
types could serialize to the same data, admittedly.)

The Java serialized form does serialize all the fields in order, I
believe.

Jon

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Regd: How do I represent java.util.Date in my .proto definition?

[Jon Skeet]

A java.util.Date doesn't contain a timezone anyway - it's always UTC.

I've previous suggested (but made no progress on) a set of common
protocol buffer messages which could be used for various products,
with helper libraries for popular platforms providing conversions
between the messages and more idiomatic types (e.g. Date on Java,
DateTime/DateTimeOffset on .NET).

Jon

On Nov 11, 12:44 am, Dan lozi...@gmail.com wrote:
 I use a dateFormatter to send it as a string.  I suppose its also
 possible to send it as a int64 if you want.  Just be wary of
 timezones.

 Dan

 On Nov 10, 3:25 pm, rahul prasad rahu...@gmail.com wrote:



  How do I represent java.util.Date in my .proto definition? Is this
  supported, or any other workaround for doing this?

  Regards,
  Rahul Prasad
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Error parsing from InputStream

[Jon Skeet]

On Nov 28, 11:35 am, Hershiv Haria darkmaste...@gmail.com wrote:
 By libprotobuf.jar I assume you mean the classes compiled during
 installation?

Not sure exactly what you mean by installation here - but you should
have a jar file created from Google source code, *not* generated by
protoc in response to your .proto files.

 I have them in the build path, and they work on the java tutorial
 project from the protobuf site.

If the tutorial project works, then you've definitely got the right
jar files around.

 Is there any other reason it wouldn't find the class?

Well, it looks like you're using Jetty. I suggest you consult the
Jetty documentation to find out where it expects to find libraries.

Jon

--

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] ByteString hash code... would anyone expect it to be portable?

[Jon Skeet]

I've been contact by Ayende Rahien with regard to some optimisations
he's been making. Some of these may be due to profiler artefacts, but
he's concerned about the hash code of ByteString.

The full blog post is here:

http://ayende.com/Blog/archive/2009/12/30/when-mini-benchmarks-are-important.aspx

Various commenters have commented that the hash code for ByteString is
pretty bad. It's relatively easy to fix (without going to the extremes
mentioned in the blog post - I don't want to use unsafe code) but that
*would* mean losing compatibility with the hash code given by Java. I
don't personally have a problem with that - hash codes should almost
never treated as persistable - but I wanted to check with others
before making a change.

Any thoughts?

Jon

--

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: ByteString hash code... would anyone expect it to be portable?

[Jon Skeet]

I had assumed that I *had* ported it from the Java - I have no idea
why I'd do anything else.

However, it certainly doesn't look anything like even r2 of the Java
code, so I'm very confused. I'll port it to look like the Java code :)

Jon

On Dec 31, 5:36 pm, Kenton Varda ken...@google.com wrote:
 I think even if some people do persist hash codes, it's worth breaking them
 to fix that hash function.  I guess you didn't directly port from the Java
 code in this case?



 On Thu, Dec 31, 2009 at 3:43 AM, Jon Skeet sk...@pobox.com wrote:
  I've been contact by Ayende Rahien with regard to some optimisations
  he's been making. Some of these may be due to profiler artefacts, but
  he's concerned about the hash code of ByteString.

  The full blog post is here:

 http://ayende.com/Blog/archive/2009/12/30/when-mini-benchmarks-are-im...

  Various commenters have commented that the hash code for ByteString is
  pretty bad. It's relatively easy to fix (without going to the extremes
  mentioned in the blog post - I don't want to use unsafe code) but that
  *would* mean losing compatibility with the hash code given by Java. I
  don't personally have a problem with that - hash codes should almost
  never treated as persistable - but I wanted to check with others
  before making a change.

  Any thoughts?

  Jon

  --

  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.c 
  om
  .
  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.

[protobuf] protobuf-csharp-port: binary and source release

[Jon Skeet]

Hi all,

I've recently been asked to put together a release of the protobuf-
csharp-port project. The binaries and source for this version (0.9)
can now be downloaded from the download page:
http://code.google.com/p/protobuf-csharp-port/downloads/list

It's 0.9 because I suspect I'll want to tune the release process -
the code should be fine, although obviously there's more I want to do
to it. (It's a while since I've checked everything that's been
happening in the Java world, for example... and I definitely want to
get protogen working as a protoc plugin at some point.)

In other news, I've been considering moving from the somewhat awkward
github + svn source control I've currently got to *just* Mercurial
hosted on Google Code. Same distributed source control goodness, but
all in the same place as the rest of the project. Any thoughts?

Jon

-- 
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: protobuf-csharp-port: binary and source release

[Jon Skeet]

On Apr 1, 9:37 pm, Kenton Varda ken...@google.com wrote:
 3 Mercurial

 (I plan to switch protobufs to it at some point...)

In that case, I suggest we try to sync up and move at roughly the same
time. I'd be very interested in hearing any dissenting opinions. (I
suspect I'm more likely to have github fans who don't want to lose
that than svn fans who won't use Mercurial.)

Jon

-- 
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] C# port: new version available (v0.9.1)

[Jon Skeet]

Hi folks,

Today I had a significant bug reported in terms of the handling of packed
fields in my C# port - unless you fetched the serialized size explicitly,
the code wouldn't serialize the packed field properly. Annoyingly, I missed
the fix when it went into the Java code (where it was previously problematic
in the same way).

I've now fixed the problem, and pushed the source changes to both svn and
github. New binaries and a source zip file are on the project page too. I
recommend that any users of my port upgrade immediately.

Jon

-- 
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: How to use Protocol buffers in visual studio c#.net

[Jon Skeet]

On Dec 9, 2:06 pm, vinu vinodkumara...@gmail.com wrote:
 Any body please send me any example program and how to use protocol
 buffers in c#.net visual stduio

Well, we have a short tutorial on the C# port page:
http://code.google.com/p/protobuf-csharp-port/wiki/GettingStarted

We have three significant updates coming down the pipe:
- An implementation of the lite runtime
- A new set of build scripts (replacing NAnt with msbuild 4)
- Improved code generation, including running protoc automatically,
providing options on the command line instead of in the proto file,
and removing the options dependency from the generated code

I'm hoping to land these before Christmas.

Jon

-- 
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: building .proto files from Visual Studio 2010 for C#

[Jon Skeet]

I don't build it in the GUI anywhere - just building in Visual Studio
doesn't rebuild the proto files.

They only get rebuilt when we manually run the build from the command
line.

Someone *did* mail me with a Visual Studio plugin to do with .proto
files, but I haven't got round to looking at it yet.

Jon

On Sep 5, 4:13 pm, lasse l...@schouw.me wrote:
 How can I setup automatic build of .proto files in Visual Studio 2010?

 I can see that protobuf-csharp-port does it but I have problems
 finding where is set in the VS2010 GUI.
 When I look in the Common.targets file I can find this:

   Target Name=_GenerateSource
     Exec Command=$(ProtocExePath) --proto_path=$(ProtosDirectory) --
 descriptor_set_out=compiled.pb @(Protos-'%(RelativeDir)%(Filename)%
 (Extension)', ' ') WorkingDirectory=$(BuildTempDirectory) /
     Exec Command=$(ProtogenExePath) compiled.pb WorkingDirectory=$
 (BuildTempDirectory) /
   /Target

 but where is it used?

 source:  http://code.google.com/p/protobuf-csharp-port/

 Lasse

-- 
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Plans to support C#?

[Jon Skeet]

On Monday, 22 September 2014 05:47:04 UTC+1, RyanE wrote:

  Are there any plans to add C# to the list of supported language for 
 Protocol Buffers in 2015 or sooner?


There are already two mature implementations - protobuf-net 
(https://code.google.com/p/protobuf-net/) and protobuf-csharp-port 
(https://code.google.com/p/protobuf-csharp-port/). The latter is my 
project, and while it's been slumbering somewhat recently, I plan to get 
back into it soon to support the newer features such as oneof. I haven't 
yet decided exactly how many of the Java API changes I'll port across - 
time will tell. Is there any specific feature you're looking for which 
isn't supported by either of these projects?

Jon

-- 
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Plans to support C#?

[Jon Skeet]

Yes, oneof support would probably be the top of my list :)

We clearly need to support the whole proto language - but there are Java 
API changes which may not be as useful in the C# community which aren't 
really part of the proto language itself.

This quarter is becoming incredibly busy for me, but it's useful to know 
that there's some pent up demand...

Jon


On Wednesday, 1 October 2014 19:28:07 UTC+1, Brian Banks wrote:

 Jon, for me personally, I'd really like support for the new oneof field.

 Glad to see you have plans to update it. I appreciate your work.

 On Tuesday, September 23, 2014 6:37:36 AM UTC-7, Jon Skeet wrote:

 On Monday, 22 September 2014 05:47:04 UTC+1, RyanE wrote:

  Are there any plans to add C# to the list of supported language for 
 Protocol Buffers in 2015 or sooner?


 There are already two mature implementations - protobuf-net (
 https://code.google.com/p/protobuf-net/) and protobuf-csharp-port (
 https://code.google.com/p/protobuf-csharp-port/). The latter is my 
 project, and while it's been slumbering somewhat recently, I plan to get 
 back into it soon to support the newer features such as oneof. I haven't 
 yet decided exactly how many of the Java API changes I'll port across - 
 time will tell. Is there any specific feature you're looking for which 
 isn't supported by either of these projects?

 Jon



-- 
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

[Jon Skeet]

That looks like you're expecting a protobuf.net-style approach - to which 
the answer is no and will continue to be no.

The C# support will continue to be based on generated code, but there's a 
new code generator and runtime now in the master branch. The main changes 
from the previous code are:

- proto3-only support (no proto2 at all)
- mutable generated types rather than the Java-style builders and immutable 
messages

Jon

On Monday, 3 August 2015 22:50:06 UTC+1, The Nguyen Xuan wrote:

 Does this version support object type in C# ?

 ex:

 [ProtoMember(1)]
 public object A {get;set;}

 thank.

 Vào 11:51:01 UTC+7 Thứ Năm, ngày 11 tháng 12 năm 2014, Feng Xiao đã viết:

 Hi all,

 I just published protobuf v3.0.0-alpha-1 on our github site:
 https://github.com/google/protobuf/releases/tag/v3.0.0-alpha-1

 This is the first alpha release of protobuf v3.0.0. In protobuf v3.0.0, 
 we will add a new protobuf language version (aka proto3) and support a 
 wider range of programming languages (to name a few: ruby, php, node.js, 
 objective-c). This alpha version contains C++ and Java implementation with 
 partial proto3 support (see below for details). In future releases we will 
 add support for more programming languages and implement the full proto3 
 feature set. Besides proto3, this alpha version also includes two other new 
 features: map fields and arena allocation. They are implemented for both 
 proto3 and the old protobuf language version (aka proto2).

 We are currently working on the documentation of these new features and 
 when it's ready it will be updated to our protobuf developer guide 
 https://developers.google.com/protocol-buffers/docs/overview. For the 
 time being if you have any questions regarding proto3 or other new 
 features, please post your question in the discussion group.

 CHANGS
 ===
 Version 3.0.0-alpha-1 (C++/Java):

   General
   * Introduced Protocol Buffers language version 3 (aka proto3).

 When protobuf was initially opensourced it implemented Protocol 
 Buffers
 language version 2 (aka proto2), which is why the version number
 started from v2.0.0. From v3.0.0, a new language version (proto3) is
 introduced while the old version (proto2) will continue to be 
 supported.

 The main intent of introducing proto3 is to clean up protobuf before
 pushing the language as the foundation of Google's new API platform.
 In proto3, the language is simplified, both for ease of use and  to
 make it available in a wider range of programming languages. At the
 same time a few features are added to better support common idioms
 found in APIs.

 The following are the main new features in language version 3:

   1. Removal of field presence logic for primitive value fields, 
 removal
  of required fields, and removal of default values. This makes 
 proto3
  significantly easier to implement with open struct 
 representations,
  as in languages like Android Java, Objective C, or Go.
   2. Removal of unknown fields.
   3. Removal of extensions, which are instead replaced by a new 
 standard
  type called Any.
   4. Fix semantics for unknown enum values.
   5. Addition of maps.
   6. Addition of a small set of standard types for representation of 
 time,
  dynamic data, etc.
   7. A well-defined encoding in JSON as an alternative to binary proto
  encoding.

 This release (v3.0.0-alpha-1) includes partial proto3 support for C++ 
 and
 Java. Items 6 (well-known types) and 7 (JSON format) in the above 
 feature
 list are not implemented.

 A new notion syntax is introduced to specify whether a .proto file
 uses proto2 or proto3:

   // foo.proto
   syntax = proto3;
   message Bar {...}

 If omitted, the protocol compiler will generate a warning and 
 proto2 will
 be used as the default. This warning will be turned into an error in a
 future release.

 We recommend that new Protocol Buffers users use proto3. However, we 
 do not
 generally recommend that existing users migrate from proto2 from 
 proto3 due
 to API incompatibility, and we will continue to support proto2 for a 
 long
 time.

   * Added support for map fields (implemented in C++/Java for both proto2 
 and
 proto3).

 Map fields can be declared using the following syntax:

   message Foo {
 mapstring, string values = 1;
   }

 Data of a map field will be stored in memory as an unordered map and 
 it
 can be accessed through generated accessors.

   C++
   * Added arena allocation support (for both proto2 and proto3).

 Profiling shows memory allocation and deallocation constitutes a 
 significant
 fraction of CPU-time spent in protobuf code and arena allocation is a
 technique introduced to reduce this cost. With arena allocation, new
 objects will be allocated from a large piece of preallocated memory 

[protobuf] Re: Missing has method for optional fields in proto3 ?

[Jon Skeet]

On Friday, 17 July 2015 02:34:21 UTC+1, Wu XIANG wrote:


   Is it true that has methods for optional fields in proto3 are removed 
 from generated message ?


For primitive types, yes.
 

   If so, how can I decide if this field has been set or not ?


You can't. An int32 field that's been set to 0 is exactly the same as an 
int32 field that hasn't been set at all.

(For oneofs, you could still tell that it was the int32 field that was set, 
so that's slightly difference.)

From the documentation:

 Note that for scalar message fields, once a message is parsed there's no 
way of telling whether a field was explicitly set to the default value (for 
example whether a boolean was set to false) or just not set at all: you 
should bear this in mind when defining your message types.

If you need a field which is an int32 value, or not set you can use the 
google.protobuf.Int32Value message type.

Jon

-- 
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: [csharp] Prescribed method to extend generated stubs and protobuf/builder classes?

[Jon Skeet]

Extension methods work if you're not planning on adding fields - but it 
means you can't add properties either, of course.

I certainly intend people to be able to use partial classes - that's why 
they're generated as partial. As mentioned, maybe I should just remove the 
attribute...

Jon


On Monday, 26 October 2015 17:48:01 UTC+2, Rob Cecil wrote:
>
> Not off hand. I was also thinking this morning that extension classes 
> could be used, if you were NOT planning on supporting extension through 
> partial definitions. Almost as good.
>
> Rob
>
> On Sunday, October 25, 2015 at 11:24:25 AM UTC-4, Jon Skeet wrote:
>>
>> Hmm. Good question. I had certainly intended for these classes to be 
>> "expanded" using partial classes (as I've done for some of the well-known 
>> types, for example).
>>
>> It's possible that we should just remove the attribute from the class 
>> declaration, possibly adding either this attribute or others to individual 
>> properties etc. Do you have any particular views on which attributes you 
>> *would* like to be applied where?
>>
>> Jon
>>
>> On Friday, 23 October 2015 21:53:32 UTC+1, Rob Cecil wrote:
>>>
>>> I noticed that the typical protobuf class looks like::
>>>
>>> public sealed partial class OpenViewRequest : pb::IMessage<
>>> OpenViewRequest> {
>>>
>>>
>>>
>>> Which rules out derived classes, but not partials. However, the whole 
>>> class is decorated with DebuggerNonUserCode, which interferes with 
>>> debugging my partial definition.
>>>
>>> Should I avoid this?
>>>
>>> I'm just defining additional ctors that take data classes.
>>>
>>> Thanks
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: [csharp] Prescribed method to extend generated stubs and protobuf/builder classes?

[Jon Skeet]

Hmm. Good question. I had certainly intended for these classes to be 
"expanded" using partial classes (as I've done for some of the well-known 
types, for example).

It's possible that we should just remove the attribute from the class 
declaration, possibly adding either this attribute or others to individual 
properties etc. Do you have any particular views on which attributes you 
*would* like to be applied where?

Jon

On Friday, 23 October 2015 21:53:32 UTC+1, Rob Cecil wrote:
>
> I noticed that the typical protobuf class looks like::
>
> public sealed partial class OpenViewRequest : pb::IMessage > {
>
>
>
> Which rules out derived classes, but not partials. However, the whole 
> class is decorated with DebuggerNonUserCode, which interferes with 
> debugging my partial definition.
>
> Should I avoid this?
>
> I'm just defining additional ctors that take data classes.
>
> Thanks
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Override ToString behavior in ProtoBuf 3 C# implementation

[Jon Skeet]

The C# codegen only works for proto3 anyway.

Out of your examples, I'd use Duration and Timestamp - and probably just a
string for Guid. That's the one I'd be most convinced by though, as the
difference in storage between the text and binary representation is so
high. Note that this would only be for diagnostic purposes though - the
Json formatter and parser will not use it.

(I don't know whether any other platforms support this, mind you...)

Jon
On 4 Nov 2015 8:19 p.m., "Teddy" <lostind...@gmail.com> wrote:

> Thanks for the info on Noda Time. I'll consider using Noda Time when we
> move to proto 3.
>
> The issue here is actually creating custom message for common types like
> the DateTime above (which seems to be a poor example). Other common types
> we need are guid, timespan, unix time etc. We want to have a user friendly
> representation in debugger/logs for easier debugging/troubleshooting.
>
> On Wed, Nov 4, 2015 at 12:00 PM, Jon Skeet <sk...@pobox.com> wrote:
>
>> Hmm... I posted a reply to this yesterday, but apparently it didn't make
>> it through. Let's see if this one gets through to the group.
>>
>> I've raised an issue for it on Github, but don't have any plans to
>> support it imminently.
>>
>> I would strongly urge you away from your current platform-specific
>> DateTime representation. If you can, use the Timestamp well-known type,
>> which has a custom Json representation. If not, consider another
>> platform-neutral representation which is likely to be more readable in a
>> string form anyway. (DateTime is somewhat broken as a type anyway. When
>> Noda Time 2.0 is out, I intend to create another Nuget package to bridge
>> that and Protobuf. The choice of nanosecond precision in Noda Time 2.0 was
>> influenced by proto3.)
>>
>> Jon
>> On 4 Nov 2015 7:51 p.m., "Teddy Zhang" <lostind...@gmail.com> wrote:
>>
>>> +Jon who seems to be the developer on this.
>>>
>>> On Monday, November 2, 2015 at 6:18:27 PM UTC-8, Teddy Zhang wrote:
>>>>
>>>> I need to override the ToString behavior in C# to make it human
>>>> readable.
>>>>
>>>> E.g. I defined a message type to represent DateTime in C#, and then
>>>> write a partial class to make it be able to convert from/to DateTime.
>>>>
>>>>> message ProtoDateTime
>>>>>
>>>>> {
>>>>>
>>>>>  sfixed64 BinaryData = 1;
>>>>>
>>>>> }
>>>>>
>>>>
>>>> However, the default ToString() doesn't generate human readable
>>>> contents.
>>>>
>>>> Currently the default implantation is (codegen code):
>>>>
>>>> public override string ToString() {
>>>>
>>>> return pb::JsonFormatter.Default.Format(this);
>>>>
>>>> }
>>>> Which will generate something like this, which is not readable.
>>>> { "dateTime": { "binaryData": "5247507155853679530" } }
>>>>
>>>> Is there a way to override this behavior?
>>>> If not, is there a plan to support this? Thanks.
>>>>
>>>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Override ToString behavior in ProtoBuf 3 C# implementation

[Jon Skeet]

The Github issue is this one, by the way:

https://github.com/google/protobuf/issues/933

Note that an alternative for debugging would be to use a
DebuggerDisplayAttribute applied on the partial class. Haven't tried this
myself, but will look into it.

Jon


On 4 November 2015 at 20:25, Jon Skeet <sk...@pobox.com> wrote:

> The C# codegen only works for proto3 anyway.
>
> Out of your examples, I'd use Duration and Timestamp - and probably just a
> string for Guid. That's the one I'd be most convinced by though, as the
> difference in storage between the text and binary representation is so
> high. Note that this would only be for diagnostic purposes though - the
> Json formatter and parser will not use it.
>
> (I don't know whether any other platforms support this, mind you...)
>
> Jon
> On 4 Nov 2015 8:19 p.m., "Teddy" <lostind...@gmail.com> wrote:
>
>> Thanks for the info on Noda Time. I'll consider using Noda Time when we
>> move to proto 3.
>>
>> The issue here is actually creating custom message for common types like
>> the DateTime above (which seems to be a poor example). Other common types
>> we need are guid, timespan, unix time etc. We want to have a user friendly
>> representation in debugger/logs for easier debugging/troubleshooting.
>>
>> On Wed, Nov 4, 2015 at 12:00 PM, Jon Skeet <sk...@pobox.com> wrote:
>>
>>> Hmm... I posted a reply to this yesterday, but apparently it didn't make
>>> it through. Let's see if this one gets through to the group.
>>>
>>> I've raised an issue for it on Github, but don't have any plans to
>>> support it imminently.
>>>
>>> I would strongly urge you away from your current platform-specific
>>> DateTime representation. If you can, use the Timestamp well-known type,
>>> which has a custom Json representation. If not, consider another
>>> platform-neutral representation which is likely to be more readable in a
>>> string form anyway. (DateTime is somewhat broken as a type anyway. When
>>> Noda Time 2.0 is out, I intend to create another Nuget package to bridge
>>> that and Protobuf. The choice of nanosecond precision in Noda Time 2.0 was
>>> influenced by proto3.)
>>>
>>> Jon
>>> On 4 Nov 2015 7:51 p.m., "Teddy Zhang" <lostind...@gmail.com> wrote:
>>>
>>>> +Jon who seems to be the developer on this.
>>>>
>>>> On Monday, November 2, 2015 at 6:18:27 PM UTC-8, Teddy Zhang wrote:
>>>>>
>>>>> I need to override the ToString behavior in C# to make it human
>>>>> readable.
>>>>>
>>>>> E.g. I defined a message type to represent DateTime in C#, and then
>>>>> write a partial class to make it be able to convert from/to DateTime.
>>>>>
>>>>>> message ProtoDateTime
>>>>>>
>>>>>> {
>>>>>>
>>>>>>  sfixed64 BinaryData = 1;
>>>>>>
>>>>>> }
>>>>>>
>>>>>
>>>>> However, the default ToString() doesn't generate human readable
>>>>> contents.
>>>>>
>>>>> Currently the default implantation is (codegen code):
>>>>>
>>>>> public override string ToString() {
>>>>>
>>>>> return pb::JsonFormatter.Default.Format(this);
>>>>>
>>>>> }
>>>>> Which will generate something like this, which is not readable.
>>>>> { "dateTime": { "binaryData": "5247507155853679530" } }
>>>>>
>>>>> Is there a way to override this behavior?
>>>>> If not, is there a plan to support this? Thanks.
>>>>>
>>>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Override ToString behavior in ProtoBuf 3 C# implementation

[Jon Skeet]

Hmm... I posted a reply to this yesterday, but apparently it didn't make it
through. Let's see if this one gets through to the group.

I've raised an issue for it on Github, but don't have any plans to support
it imminently.

I would strongly urge you away from your current platform-specific DateTime
representation. If you can, use the Timestamp well-known type, which has a
custom Json representation. If not, consider another platform-neutral
representation which is likely to be more readable in a string form anyway.
(DateTime is somewhat broken as a type anyway. When Noda Time 2.0 is out, I
intend to create another Nuget package to bridge that and Protobuf. The
choice of nanosecond precision in Noda Time 2.0 was influenced by proto3.)

Jon
On 4 Nov 2015 7:51 p.m., "Teddy Zhang"  wrote:

> +Jon who seems to be the developer on this.
>
> On Monday, November 2, 2015 at 6:18:27 PM UTC-8, Teddy Zhang wrote:
>>
>> I need to override the ToString behavior in C# to make it human readable.
>>
>> E.g. I defined a message type to represent DateTime in C#, and then write
>> a partial class to make it be able to convert from/to DateTime.
>>
>>> message ProtoDateTime
>>>
>>> {
>>>
>>>  sfixed64 BinaryData = 1;
>>>
>>> }
>>>
>>
>> However, the default ToString() doesn't generate human readable contents.
>>
>> Currently the default implantation is (codegen code):
>>
>> public override string ToString() {
>>
>> return pb::JsonFormatter.Default.Format(this);
>>
>> }
>> Which will generate something like this, which is not readable.
>> { "dateTime": { "binaryData": "5247507155853679530" } }
>>
>> Is there a way to override this behavior?
>> If not, is there a plan to support this? Thanks.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Override ToString behavior in ProtoBuf 3 C# implementation

[Jon Skeet]

Firstly, I'd encourage you not to do that:

a) this opaque binary data goes against the general aims of protos being 
cross-platform. That may not be a requirement for you at the moment, but 
I'd urge you to at least bear it in mind
b) unless you really need DateTime's somewhat odd semantics 
(http://blog.nodatime.org/2011/08/what-wrong-with-datetime-anyway.html) I'd 
encourage you to use the well-known Timestamp type. There are conversions 
available within that already, and it has a custom format which is 
basically ISO-8601.

As an aside, at some point after Noda Time 2.0 has landed, I expect to 
create a NodaTime.Protobuf nuget package which adds conversions between 
Instant and Timestamp, and NodaTime.Duration and 
Google.Protobuf.WellKnownTypes.Duration too. The nanosecond precision in 
protobuf was a contributing factor to the decision to use nanosecond 
precision in Noda Time 2.0. Just something to bear in mind if you were 
already considering Noda Time.

Now, all that aside, I can see cases where it might make sense. I've 
filed https://github.com/google/protobuf/issues/933 to capture this, partly 
so that others could add their use cases to it. The proposed way of 
implementing it would be a somewhat grotty hack though, using a partial 
method with a ref parameter. Other ideas would be welcome...

Jon

On Tuesday, 3 November 2015 02:18:27 UTC, Teddy Zhang wrote:
>
> I need to override the ToString behavior in C# to make it human readable.
>
> E.g. I defined a message type to represent DateTime in C#, and then write 
> a partial class to make it be able to convert from/to DateTime.
>
>> message ProtoDateTime
>>
>> {
>>
>>  sfixed64 BinaryData = 1;
>>
>> }
>>
>
> However, the default ToString() doesn't generate human readable contents.
>
> Currently the default implantation is (codegen code):
>
> public override string ToString() {
>
> return pb::JsonFormatter.Default.Format(this);
>
> }
> Which will generate something like this, which is not readable.
> { "dateTime": { "binaryData": "5247507155853679530" } }
>
> Is there a way to override this behavior?
> If not, is there a plan to support this? Thanks.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] Newest version of Protobuf that will work with Java and MSVC# 2008?

[Jon Skeet]

The code we *generate* only uses C# 3 - so anything from VS2008 onwards. In 
other words, you should be fine on this front.

Currently the runtime library code is also C# 3 as far as I'm aware... 
however, I'm intending to start using C# 6 features at some point in the 
not-too-distant future, in order to clean up the code. This won't change 
which platforms we target though. The expectation is that most people won't 
need to build the runtime from source anyway - they'll use the NuGet 
package. 

However, depending on what version of .NET your "Smart Mobile Device 
hardware" supports, it could be that the runtime library won't support your 
platform anyway. Back in the days of protobuf-csharp-port 
<https://github.com/jskeet/protobuf-csharp-port>, we tried to support a 
huge range of platforms (.NET 2, various flavours of Silverlight etc) and 
it was nasty. I'm expecting the initial release of the Google.Protobuf 
package to *only* support Portable Class Libraries, with profile 259. I'm 
afraid if your platform doesn't support that, that may be a big blocker. Of 
course we would *like* to support lots of platforms, but there's a 
complexity/maintainability cost as well - and I'd rather have a great, 
maintainable experience that works for 95% of users than one which works 
"okay" for 97% but which is too painful too improve.

As an aside, I'd expect you to be able to install VS2015 alongside VS2008 
with no problems, which may help with the *immediate* issue of building the 
runtime (and protoc), but won't remove the blocker of which platforms are 
targeted.

Jon

On Wednesday, 7 October 2015 02:33:41 UTC+1, Feng Xiao wrote:
>
>
> On Sat, Oct 3, 2015 at 3:48 PM, Dylan Justice <dylanj...@gmail.com 
> > wrote:
>
>> I've been trying for a good part of the day to build Protobuf 
>> v3.0.0-beta-1 for C# in MSVS 2008 -- the most recent version of Visual 
>> Studio that can target my Smart Mobile Device hardware.  I'm starting to 
>> believe that this task is impossible.  The Cmake files don't seem to work, 
>> and the .SLN and .CSPROJ files appear to be v14, which can't be imported by 
>> MSVS v9.  
>>
> +Jon Skeet, what's the minimum Visual Studio version required for protobuf 
> C#?
>  
>
>>
>> I haven't gone so far as to manually recreate VS2008 projects for 
>> Protobuf 3 from scratch.  Has anyone here done this?
>>
>> Assuming that this is a fool's errand, what's my best option for Protobuf 
>> compatibility between Java (Android) and VS2008 C#?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Protocol Buffers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to protobuf+u...@googlegroups.com .
>> To post to this group, send email to prot...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/protobuf.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1

[Jon Skeet]

Yes, just to expand on this - the descriptor protos aren't directly 
accessible, but the information contained within them is - via the public 
types in the Google.Protobuf.Reflection namespace.

We're able to do this because we've looked (very carefully!) at how 
descriptor.proto works in terms of proto3 - basically we generate code *as 
if* it were proto3 syntax, and have workarounds for couple of issues that 
throws up.

Jon

On Friday, 9 October 2015 19:18:42 UTC+1, Feng Xiao wrote:
>
> On Fri, Oct 9, 2015 at 10:51 AM, Walter Schulze <awalter...@gmail.com 
> > wrote:
>
>> In other words C# and those new languages won't be able to serialize the 
>> descriptor?
>>
> descriptor.proto is an exception. It's allowed to be imported by proto3 
> files to support custom options. I.e., the following is explicitly allowed:
> syntax = "proto3";
> package test;
>
> *import "google/protobuf/descriptor.proto";*
>
> *extend google.protobuf.FieldOptions {*
> *  string my_field_option = 123456789;*
> *}*
>
> message TestMessage {
>   int32 value = 1 [*(my_field_option) = "Some extra option data"*];
> }
>
> However, the ability to use these descriptor info at run-time may be 
> limited (or not present) in certain languages. It depends on what API is 
> provided by the specific language. +Jon Skeet could probably say more about 
> how to use/access descriptors in C#.
>
>
>  
>
>>
>> On 9 October 2015 at 19:44, 'Feng Xiao' via Protocol Buffers <
>> prot...@googlegroups.com > wrote:
>>
>>> The decision is not to support proto2 in C# (and probably also for all 
>>> other languages that are new in v3.0.0+).
>>>
>>> On Fri, Oct 9, 2015 at 10:42 AM, Teddy Zhang <losti...@gmail.com 
>>> > wrote:
>>>
>>>> Will the C# implementation support proto2 message as well?
>>>> What is the compatibility story between proto2 and proto 3? I assume 
>>>> the wire format is compatible as long as no proto 3 exclusive features 
>>>> are used.
>>>>
>>>>
>>>> On Tuesday, August 4, 2015 at 5:43:36 AM UTC-7, Jon Skeet wrote:
>>>>
>>>>> That looks like you're expecting a protobuf.net-style approach - to 
>>>>> which the answer is "no" and will continue to be "no".
>>>>>
>>>>> The C# support will continue to be based on generated code, but 
>>>>> there's a new code generator and runtime now in the master branch. The 
>>>>> main 
>>>>> changes from the previous code are:
>>>>>
>>>>> - proto3-only support (no proto2 at all)
>>>>> - mutable generated types rather than the Java-style builders and 
>>>>> immutable messages
>>>>>
>>>>> Jon
>>>>>
>>>>> On Monday, 3 August 2015 22:50:06 UTC+1, The Nguyen Xuan wrote:
>>>>>>
>>>>>> Does this version support object type in C# ?
>>>>>>
>>>>>> ex:
>>>>>>
>>>>>> [ProtoMember(1)]
>>>>>> public object A {get;set;}
>>>>>>
>>>>>> thank.
>>>>>>
>>>>>> Vào 11:51:01 UTC+7 Thứ Năm, ngày 11 tháng 12 năm 2014, Feng Xiao đã 
>>>>>> viết:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I just published protobuf v3.0.0-alpha-1 on our github site:
>>>>>>> https://github.com/google/protobuf/releases/tag/v3.0.0-alpha-1
>>>>>>>
>>>>>>> This is the first alpha release of protobuf v3.0.0. In protobuf 
>>>>>>> v3.0.0, we will add a new protobuf language version (aka proto3) and 
>>>>>>> support a wider range of programming languages (to name a few: ruby, 
>>>>>>> php, 
>>>>>>> node.js, objective-c). This alpha version contains C++ and Java 
>>>>>>> implementation with partial proto3 support (see below for details). In 
>>>>>>> future releases we will add support for more programming languages and 
>>>>>>> implement the full proto3 feature set. Besides proto3, this alpha 
>>>>>>> version 
>>>>>>> also includes two other new features: map fields and arena allocation. 
>>>>>>> They 
>>>>>>> are implemented for both proto3 and the old protobuf language version 
>>>>>>> (aka 
&

[protobuf] Re: How can I use FileDescriptorSet in my own proto3 message with C# 3.0.0-alpha4?

[Jon Skeet]

Possibly. Although it may end up being more confusing than useful - and 
could easily get out of date if we provide some sort of support.
(And as mentioned, you could potentially use a bytes field instead, when we 
have dynamic message support.)

I'll reach out to our tech writers and see what they think...

Jon

On Monday, 7 December 2015 20:24:56 UTC, James Hugard wrote:
>
> Would it be worth mentioning on the Google documentation pages that 
> Self-Describing messages are not supported in Proto3?
>
> https://developers.google.com/protocol-buffers/docs/techniques
>
>
> jh
>
>
> On Thursday, December 3, 2015 at 4:46:29 AM UTC-8, Jon Skeet wrote:
>>
>> I agree it's a limitation - but it just comes naturally with the 
>> territory of only supporting proto3.
>>
>> Now there's nothing to say that we'll *never* support proto2 - but the 
>> extra complexity of supporting extensions and different models of field 
>> presence would have significantly delayed the whole effort. (It would also 
>> have made the code base harder to maintain - I'm much happier with the new 
>> code base than the old proto2-only one...)
>>
>> Jon
>>
>> On Wednesday, 2 December 2015 16:56:12 UTC, James Hugard wrote:
>>>
>>> Hi Jon:
>>>
>>> Pity that there will be no official support.  That means I shall be 
>>> unable to have fully self-describing messages.  Further, I believe that 
>>> will also preclude writing proto compiler plugins in C# (F#, VB, etc.).
>>>
>>> As an interim solution (or a permanent one?), I have hand-edited 
>>> Descriptor.proto to remove everything incompatible with proto3, compiled it 
>>> with proto3 syntax, thus generating C# code. The main issue is support for 
>>> extension ranges - without those, it is impossible to declare custom 
>>> options (which we also use).  Therefore, I simply compiled all other proto 
>>> files using the original (proto2) descriptor.proto file then hand edited 
>>> the generated code to reference 
>>> Google.ProtocolBuffers.DescriptorProtos.FileDescriptorProto.  
>>>
>>> Less than ideal, and certainly not acceptable for production use.
>>>
>>> I'm eyeing the Froto <https://github.com/ctaggart/froto> project as a 
>>> possible long-term solution, but with a need to support many languages 
>>> that's also less than ideal and would take .NET out of the primary 
>>> ecosystem.
>>>
>>> Thanks for the reply!
>>>
>>> jh
>>>
>>>
>>> On Wednesday, December 2, 2015 at 6:46:52 AM UTC-8, Jon Skeet wrote:
>>>>
>>>> On Wednesday, 2 December 2015 04:45:30 UTC, James Hugard wrote:
>>>>>
>>>>> Trying to use a FileDescriptorSet in my own proto3 message definition 
>>>>> with C# 3.0.0-alpha4 generated code, but running into compilation issues.
>>>>>
>>>>> The code generates just fine using protoc.exe, but the generated code 
>>>>> won't compile due to a missing reference to "global
>>>>> ::Google.Protobuf.FileDescriptorSet".
>>>>>
>>>>> Attempting to generate code from the protobuf definition fails, 
>>>>> because the Descriptor.proto file uses proto2 syntax and hence is not 
>>>>> supported by the C# code generator.
>>>>>
>>>>> A C# object for FileDescriptorSet does not appear to be in 
>>>>> Google.Protobuf assembly.  Nor could I figure out how to modify the 
>>>>> generated code to compile properly.  Attempting to manually edit the 
>>>>> generated code to use 
>>>>>
>>>>> Google.Protobuf.Collections.RepeatedField< 
>>>>> Google.Protobuf.Reflection.FileDescriptor > failed with a "no 
>>>>> conversion to IMessage<>", or something similar.
>>>>>
>>>>>
>>>>> Please, what is the right way to use a FileDescriptorSet in my own 
>>>>> proto?
>>>>>
>>>>
>>>> I'm afraid you can't. We generate the code for descriptor.proto so that 
>>>> we can use it within the protobuf runtime, but it's all internal - we 
>>>> don't 
>>>> have any codegen to support proto2 semantics, and we've carefully looked 
>>>> at 
>>>> what we need from descriptor.proto to check that it's okay with what we 
>>>> need to use it for internally, but that's all. It would be a bad idea to 
>>>> expose it separately.
>>>>
>>>> If we ever retroactively fit proto2 support, that would be fine, of 
>>>> course - but until then, I'm afraid there's no way of doing this. You 
>>>> could 
>>>> create your own proto3 copy of descriptor.proto, taking only the bits you 
>>>> care about, and if you're very careful you *may* then be able to 
>>>> interoperate with code that actually expects a FileDescriptorSet... but 
>>>> you 
>>>> would definitely need to be careful.
>>>>
>>>> Jon
>>>>  
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: How can I use FileDescriptorSet in my own proto3 message with C# 3.0.0-alpha4?

[Jon Skeet]

On Wednesday, 2 December 2015 04:45:30 UTC, James Hugard wrote:
>
> Trying to use a FileDescriptorSet in my own proto3 message definition with 
> C# 3.0.0-alpha4 generated code, but running into compilation issues.
>
> The code generates just fine using protoc.exe, but the generated code 
> won't compile due to a missing reference to "global
> ::Google.Protobuf.FileDescriptorSet".
>
> Attempting to generate code from the protobuf definition fails, because 
> the Descriptor.proto file uses proto2 syntax and hence is not supported by 
> the C# code generator.
>
> A C# object for FileDescriptorSet does not appear to be in Google.Protobuf 
> assembly.  Nor could I figure out how to modify the generated code to 
> compile properly.  Attempting to manually edit the generated code to use 
>
> Google.Protobuf.Collections.RepeatedField< 
> Google.Protobuf.Reflection.FileDescriptor > failed with a "no conversion 
> to IMessage<>", or something similar.
>
>
> Please, what is the right way to use a FileDescriptorSet in my own proto?
>

I'm afraid you can't. We generate the code for descriptor.proto so that we 
can use it within the protobuf runtime, but it's all internal - we don't 
have any codegen to support proto2 semantics, and we've carefully looked at 
what we need from descriptor.proto to check that it's okay with what we 
need to use it for internally, but that's all. It would be a bad idea to 
expose it separately.

If we ever retroactively fit proto2 support, that would be fine, of course 
- but until then, I'm afraid there's no way of doing this. You could create 
your own proto3 copy of descriptor.proto, taking only the bits you care 
about, and if you're very careful you *may* then be able to interoperate 
with code that actually expects a FileDescriptorSet... but you would 
definitely need to be careful.

Jon
 

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: How can I use FileDescriptorSet in my own proto3 message with C# 3.0.0-alpha4?

[Jon Skeet]

I agree it's a limitation - but it just comes naturally with the territory 
of only supporting proto3.

Now there's nothing to say that we'll *never* support proto2 - but the 
extra complexity of supporting extensions and different models of field 
presence would have significantly delayed the whole effort. (It would also 
have made the code base harder to maintain - I'm much happier with the new 
code base than the old proto2-only one...)

Jon

On Wednesday, 2 December 2015 16:56:12 UTC, James Hugard wrote:
>
> Hi Jon:
>
> Pity that there will be no official support.  That means I shall be unable 
> to have fully self-describing messages.  Further, I believe that will also 
> preclude writing proto compiler plugins in C# (F#, VB, etc.).
>
> As an interim solution (or a permanent one?), I have hand-edited 
> Descriptor.proto to remove everything incompatible with proto3, compiled it 
> with proto3 syntax, thus generating C# code. The main issue is support for 
> extension ranges - without those, it is impossible to declare custom 
> options (which we also use).  Therefore, I simply compiled all other proto 
> files using the original (proto2) descriptor.proto file then hand edited 
> the generated code to reference 
> Google.ProtocolBuffers.DescriptorProtos.FileDescriptorProto.  
>
> Less than ideal, and certainly not acceptable for production use.
>
> I'm eyeing the Froto <https://github.com/ctaggart/froto> project as a 
> possible long-term solution, but with a need to support many languages 
> that's also less than ideal and would take .NET out of the primary 
> ecosystem.
>
> Thanks for the reply!
>
> jh
>
>
> On Wednesday, December 2, 2015 at 6:46:52 AM UTC-8, Jon Skeet wrote:
>>
>> On Wednesday, 2 December 2015 04:45:30 UTC, James Hugard wrote:
>>>
>>> Trying to use a FileDescriptorSet in my own proto3 message definition 
>>> with C# 3.0.0-alpha4 generated code, but running into compilation issues.
>>>
>>> The code generates just fine using protoc.exe, but the generated code 
>>> won't compile due to a missing reference to "global
>>> ::Google.Protobuf.FileDescriptorSet".
>>>
>>> Attempting to generate code from the protobuf definition fails, because 
>>> the Descriptor.proto file uses proto2 syntax and hence is not supported by 
>>> the C# code generator.
>>>
>>> A C# object for FileDescriptorSet does not appear to be in 
>>> Google.Protobuf assembly.  Nor could I figure out how to modify the 
>>> generated code to compile properly.  Attempting to manually edit the 
>>> generated code to use 
>>>
>>> Google.Protobuf.Collections.RepeatedField< 
>>> Google.Protobuf.Reflection.FileDescriptor > failed with a "no 
>>> conversion to IMessage<>", or something similar.
>>>
>>>
>>> Please, what is the right way to use a FileDescriptorSet in my own proto?
>>>
>>
>> I'm afraid you can't. We generate the code for descriptor.proto so that 
>> we can use it within the protobuf runtime, but it's all internal - we don't 
>> have any codegen to support proto2 semantics, and we've carefully looked at 
>> what we need from descriptor.proto to check that it's okay with what we 
>> need to use it for internally, but that's all. It would be a bad idea to 
>> expose it separately.
>>
>> If we ever retroactively fit proto2 support, that would be fine, of 
>> course - but until then, I'm afraid there's no way of doing this. You could 
>> create your own proto3 copy of descriptor.proto, taking only the bits you 
>> care about, and if you're very careful you *may* then be able to 
>> interoperate with code that actually expects a FileDescriptorSet... but you 
>> would definitely need to be careful.
>>
>> Jon
>>  
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: C# Enum Flags

[Jon Skeet]

On Tuesday, 24 November 2015 19:36:11 UTC, Teddy Zhang wrote:
>
> How do I store a HashSet with protobuf?
>

Have a repeated field of the enum type, so that you get a collection - and 
then make sure you transform it into a set in your code. proto doesn't have 
the notion of a set as such.
 

> Regarding the proto2 implementation, if I defined my enum as 1, 2, 4 etc, 
> and I set the enum to value 3 (combination of 1 & 2), it serialize the 
> fields correctly. But when deserialize, I get value 0 back (as 3 is not in 
> enum).
>

Yes, because that's the defined behaviour in proto2 for an undefined value. 
You're trying to use proto enums in a way that they weren't designed for, 
which is never going to be a pleasant experience. It's not about being a 
"combination" of values - proto doesn't have any such concept. It's just a 
value which isn't defined.

Jon

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: C++ and C# proto3 json (de)serialization

[Jon Skeet]

I'm afraid I know nothing about the most appropriate way of doing JSON 
serialization in the C++ code. It would probably be worth specifying 
exactly what you're trying to do - do you have a message and want to 
serialize it straight to a stream, or do you want to get the JSON as a 
std::string or similar?

Jon


On Monday, 23 November 2015 09:25:02 UTC, Ron wrote:
>
> Thanks Jon!
> The wrapper around C++ for JSON deserialization seems to be working well 
> so far, but since you say C# JSON deserialization has been implemented in 
> the latest release I'll probably start using that in the near future.
>
>
> Any advice regarding C++? Anyone has suggestions for JSON serialization 
> and deserialization? Is the proper way going through binary and using the 
> BinaryToJson/JsonToBinary functions? Or is there a more direct way?
>
> Thanks,
> Ron
>
>
>
> On Thursday, November 12, 2015 at 3:24:43 PM UTC+2, Jon Skeet wrote:
>>
>> C# JSON parsing went in a few days ago, actually. There may still be some 
>> discrepancies in terms of parsing JSON from third-party sources, but I'd 
>> expect parsing the JSON output of the C++ protobuf library to work. If it 
>> doesn't, please let me know!
>>
>> The one bit that *isn't* implemented (in either formatting or parsing) is 
>> the Any well-known type. That's the last big feature on my list, I believe.
>>
>> Jon
>>
>>
>> On Thursday, 12 November 2015 00:42:22 UTC, Ron wrote:
>>>
>>> So far I've been using the binary wire format, and now I'm trying to use 
>>> JSON serialization for some things and the usage seems to be somewhat 
>>> different, so looking for a little guidance.
>>>
>>> In C++, what are the possible ways to go about JSON serialization and 
>>> deserialization? So far I could only find ways that use the binary wire 
>>> format as some sort of an intermediate stage between the JSON 
>>> representation and C++ message objects. Are there any ways of doing this 
>>> that are more direct, not going through the binary wire format in between? 
>>> Also, are there any documents and/or examples for using ObjectWriter and 
>>> other proto3 classes or are they only going to be available once the final 
>>> release is out? (I saw a post here mentioning it's likely to be sometime 
>>> around Q4, is that still the case?)
>>>
>>> In C# as far as I can tell serialization can be performed using 
>>> JsonFormatter directly or through ToString() and deserialization is not 
>>> implemented yet. Is that correct? Will JSON deserialization be available in 
>>> the final release? For now I'm using a managed wrapper around the C++ 
>>> JsonToBinary() function as a temporary solution for C# JSON deserialization 
>>> and it seems to be working okay. Are there any potential pitfalls with this 
>>> approach I might be overlooking? Are there any alternatives for the time 
>>> being?
>>>
>>> Thanks in advance,
>>> Ron 
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Report a bug

[Jon Skeet]

In general, you'd report a bug at https://github.com/google/protobuf/issues

... but in this case there's no bug. This is perfectly valid C# 6, which is 
required to build the Google.Protobuf library.
The code generated by protoc *doesn't* use C# 6, so you should be fine with 
whatever you generate, and the fact that the library uses C# 6 won't stop 
the compiled code from being used by older versions of Visual Studio etc.

Basically, we require Visual Studio 2015 (or the equivalent version of the 
Mono compiler) for Google.Protobuf itself.

Jon

On Friday, 19 February 2016 23:57:10 UTC, ykwd.t...@gmail.com wrote:
>
> Hi, 
>
> Protobuf is a nice work which saves me a lot of time.
>
> Through my using, I find a bug as the following : 
>
> In some csharp source files such 
> as csharp/src/Google.Protobuf/Reflection/FieldDescriptor.cs, there are some 
> codes like :
>
> throw new DescriptorValidationException(this, $"\"{Proto.TypeName}\" is 
>> not an enum type.");
>
>
> or 
>
> string IDescriptor.FullName => Name;
>
>
> It seems that this is due to mistakes in automatic code generation.
>
> These codes cause the csharp project building failed.
>
> This bug first occurs at the submission of 
>  72ec33676fd40ccfe719ace162fcf859ae9251bc.
>
> I don't know if this is the right place to report bugs. I'm sorry if not, 
> can anyone tell me how to report it.
>
> Thanks.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: DescriptionPool / DynamicMessages in C# library

[Jon Skeet]

Yes, that approach looks like it would handle all the currently-loaded 
assemblies. I'm not sure that it would help with assemblies which were 
referenced but hadn't yet been loaded.

Ultimately, it depends on what this is for - personally I'd expect that in 
most cases it would be fine just to explicitly state up-front which 
descriptors (or at least assemblies) were involved.

Jon


On Wednesday, 9 March 2016 17:15:23 UTC, Benjamin Krämer wrote:
>
> Hi Jon,
>
> Am Mittwoch, 9. März 2016 13:59:32 UTC+1 schrieb Jon Skeet:
>>
>> Indeed there isn't. It's not clear to me at what point messages would get 
>> registered - after all, a new assembly with extra messages could be loaded 
>> at any point.
>>
>
> I'm not completely up to date on module initialization in CLR. Is there 
> still no native language support for it? I only know this 7 year old 
> workaround, but this is done after building: 
> http://einaregilsson.com/module-initializers-in-csharp/ Also I just found 
> this post about a nuget package: 
> http://geertvanhorrik.com/2013/06/28/assembly-constructors-and-initializers-using-c/
>  
> Also not a good solution for including it in a library... Would be a bit 
> sad if Microsoft still offers no support to access this CLR feature. I 
> understand that static constructors are only called when the type is 
> referenced for the first time.
>
> Another possible (also if not as performant) option I successfully tried 
> was reflection. 
> https://github.com/Falco20019/protobuf/commit/74e5a82593787610f2207423bf3a8a8449a78813
>  
> By introducing a common interface, you can look them up in the AppDomain. 
> Here is the test class I used to generate a TypeRegistry from all currently 
> loaded assemblies. This is not cached but calculated on request since new 
> assemblies can be introduced as you said.
>
> public static TypeRegistry GetTypeRegistry()
> {
> List descriptors = new List();
> AppDomain.CurrentDomain.GetAssemblies()
> .SelectMany(s => s.GetTypes())
> .Where(p => typeof(IReflection).IsAssignableFrom(p) && !p.
> IsInterface)
> .ToList()
> .ForEach(type =>
> {
> var pi = type.GetProperty("Descriptor", BindingFlags.Public | 
> BindingFlags.Static);
> var value = pi.GetValue(null);
> descriptors.Add((FileDescriptor)value);
> });
>
> return TypeRegistry.FromFiles(descriptors);
> }
>
> Calling GetValue on the property initializes the type and returns the 
> descriptor. If you only want to call your static constructor for all 
> classes, you could use 
>
> System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(type.TypeHandle);
>
> This is better than invoking TypeInitializer which leads to the 
> constructor being called multiple times (as you also wrote on StackOverflow 
> 6 years ago :) ).
>
> I also thought about just using IMessage for the lookup and use Descriptor 
> to initialize the TypeRegistry with FromMessages, but this would finds a 
> lot more types which would make the reflection part slower.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: DescriptionPool / DynamicMessages in C# library

[Jon Skeet]

On Tuesday, 8 March 2016 22:39:28 UTC, Benjamin Krämer wrote:
>
> I have ported the MessageDifferencer from C++ to C# since I need to look 
> for changes in various protos. The only thing missing is the unpacking of 
> the Any messages.
>
> Therefore I would like to get a descriptor for which I know the name and 
> which is also compiled into the application. In C++, I can use the 
> DynamicMessageFactory or look it up with DescriptorPool::generated_pool(). 
> It seems, like there is no generated or central pool in C#.
>

Indeed there isn't. It's not clear to me at what point messages would get 
registered - after all, a new assembly with extra messages could be loaded 
at any point.
 

> Each FileDescriptor seems to have it's own DescriptorPool containing only 
> it's own descriptor with it's dependencies. Also the DependencyPool in C# 
> is internal and the only way to access it seems to use the FindTypeByName 
> method of the FileDescriptor.
>
> Is it somehow possible to get the descriptor in C# or do I have to 
> aggregate the DescriptorPool by myself?
>

If you mean the descriptor proto - no, that's deliberately internal as it's 
a proto2 message; we know we don't modify it within the Google.Protobuf 
library, and have investigated all the differences in behaviour - basically 
we treat it as a proto3 message, with care. We definitely don't want to 
expose that to callers.

Jon

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Protobuf - How to create a FileDescriptor object from a Descriptor file

[Jon Skeet]

Currently this isn't supported by the C# protobuf library. There's a Github 
issue for supporting DynamicMessage - which is basically what you'd want - 
here: https://github.com/google/protobuf/issues/658

It's unlikely that we'll be supporting this for the initial GA release, but 
the more we know about your use case, the better our support is likely to 
be when it comes, so please add more context to the issue.

I note that you sent another message suggesting you'd already created an 
Example.cs file - you could compile that dynamically using Roslyn, but 
that's going in a pretty different direction than dynamic messages within 
protobuf.

Jon


On Wednesday, 30 March 2016 06:29:45 UTC+1, Raghu wrote:
>
>
> I created a Descriptor file from Example.proto file using the below 
> command.
>
> .\protoc.exe --proto_path=D:\ExampleProject\ --include_imports 
> D:\ExampleProject\Example.Proto 
> --descriptor_set_out=D:\ExampleProject\Example.pb
>
> We want to read this file and create FileDescriptorSet object in C#. But 
> both FileDescriptorSet and FileDescriptorProto are internal classes.
>
> Please let me know how to create FileDescriptor object from 
> this Example.pb file. 
>
> Note: We want to use C#.
>
> Thanks & Regards
> Raghu
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Reflecting Custom Options in Protobuf C#

[Jon Skeet]

On Thursday, 28 April 2016 22:58:42 UTC+1, TravG wrote:
>
> I'm using Protobufs in C# and wondering how I can get access to custom 
> options I've annotated on a field at runtime via reflection.  I see some 
> indications that this should be possible:
>

Hmm... I don't *think* we expose it at the moment. Will look into it. I 
don't want to expose the existing options protos for various reasons. Do 
you have a preferred API in mind? It's probably easiest to keep track of 
this as a Github feature request - are you happy to open one?

Jon 

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: using proto3 for receiving proto2 messages ("group", C#)

[Jon Skeet]

Groups are always skipped in the C# proto3 code... and the wire format is 
different to other messages anyway.

Are you concerned about doing this *in general*, or do you have actual 
messages using groups that you want to parse in C#? As far as I'm aware, 
the advice has been to avoid using groups for several years now.

Jon

On Saturday, 21 May 2016 04:26:10 UTC+1, Scobe S. wrote:
>
> Given a .proto file used with proto2 to generate code to send messages, is 
> it feasible to use proto3 on the same .proto file to receive 
> messages--assuming I alter the .proto file to be proto3 compatible?
>
> In particular, if I fix the following (which currently are errors I get 
> when compiling the .proto file in proto3), then receiving messages should 
> work, right?
>
> Don't use "required" or "optional".
> Make sure enums have a zero element as the first item.
> Don't use explicit default values.
> Do not use "group".
> (These are the only errors I have.)
>
> The one I am having real doubts and questions about is getting rid of 
> "group". Using the example in the docs, I have to take something like this:
>
> message SearchResponse {
>   repeated group Result = 1 {
> required string url = 2;
> optional string title = 3;
> repeated string snippets = 4;
>   }
> }
>
>
> and make it like this:
>
> message SearchResponse {
>   message Result {
> required string url = 1;
> optional string title = 2;
> repeated string snippets = 3;
>   }
>   repeated Result result = 1;
> }
>
>
> But this may redefine what is expected in the data over the wire. So I 
> wonder what the best way is to replace "group" to be backward compatible.
>
> BTW, my goal is to generate C#. That's why I am using proto3.
>
> Thanks.
> Scobe
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: using proto3 for receiving proto2 messages ("group", C#)

[Jon Skeet]

No, unfortunately if they're using groups in their proto files, you won't 
be able to use the proto3 C# code.
I *think* I supported groups in the proto2 port 
(https://github.com/jskeet/protobuf-csharp-port) but please be aware that 
that code is not under active development, and not officially supported by 
Google.

I would suggest coming up with a strategy to move to proto3 if you possibly 
can - maybe via some temporary migration tool that has the proto2 messages 
as input, manually converts them to the new proto3 messages, then saves the 
result.

Jon


On Tuesday, 24 May 2016 02:22:27 UTC+1, Scobe S. wrote:
>
> I have a .proto file from a third-party, developed for Protobuf 2.6.1, to 
> deserialize their data. I want to code my application to consume their data 
> in C#. So I was trying to use proto3 to compile their .proto file into C#. 
> But they have used some proto features that are not supported in proto3, 
> such as group. I modified the other places in their .proto that seemed 
> innocuous, like having a zero-element first in enums. If I could compile 
> their .proto file with proto3, then I would have hope I could deserialize 
> their data using C#.
>
> But I suspect that changes I have to make to their .proto file--esp. the 
> "group" uses--will change the assumption about the wire format
>
> As a result, if I can't compile the .proto file to C#, then I have to use 
> .NET Interop, if I want to write my app in C#. I have successfully compiled 
> their .proto file with proto2, so I have a C++ (unmanaged) DLL with their 
> proto schema in C++. But now I have to write a nasty wrapper, probably with 
> COM, to marshal their .proto C++ classes over to .NET. Their .proto schema 
> is not small, so writing a wrapper is not going to be fun.
>
> Any suggestions are much appreciated!
>
>
> On Saturday, May 21, 2016 at 6:22:00 AM UTC-7, Jon Skeet wrote:
>>
>> Groups are always skipped in the C# proto3 code... and the wire format is 
>> different to other messages anyway.
>>
>> Are you concerned about doing this *in general*, or do you have actual 
>> messages using groups that you want to parse in C#? As far as I'm aware, 
>> the advice has been to avoid using groups for several years now.
>>
>> Jon
>>
>> On Saturday, 21 May 2016 04:26:10 UTC+1, Scobe S. wrote:
>>>
>>> Given a .proto file used with proto2 to generate code to send messages, 
>>> is it feasible to use proto3 on the same .proto file to receive 
>>> messages--assuming I alter the .proto file to be proto3 compatible?
>>>
>>> In particular, if I fix the following (which currently are errors I get 
>>> when compiling the .proto file in proto3), then receiving messages should 
>>> work, right?
>>>
>>> Don't use "required" or "optional".
>>> Make sure enums have a zero element as the first item.
>>> Don't use explicit default values.
>>> Do not use "group".
>>> (These are the only errors I have.)
>>>
>>> The one I am having real doubts and questions about is getting rid of 
>>> "group". Using the example in the docs, I have to take something like this:
>>>
>>> message SearchResponse {
>>>   repeated group Result = 1 {
>>> required string url = 2;
>>> optional string title = 3;
>>> repeated string snippets = 4;
>>>   }
>>> }
>>>
>>>
>>> and make it like this:
>>>
>>> message SearchResponse {
>>>   message Result {
>>> required string url = 1;
>>> optional string title = 2;
>>> repeated string snippets = 3;
>>>   }
>>>   repeated Result result = 1;
>>> }
>>>
>>>
>>> But this may redefine what is expected in the data over the wire. So I 
>>> wonder what the best way is to replace "group" to be backward compatible.
>>>
>>> BTW, my goal is to generate C#. That's why I am using proto3.
>>>
>>> Thanks.
>>> Scobe
>>>
>>>
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: photo file compilation Error for csharp

[Jon Skeet]

Could you give more details about what you mean by "I am getting the 
compilation error" and "These commands don't work"?

I'm not sure what proton is in this case... did you mean protoc again?

I'd also be careful about putting spaces after the option names when you're 
using =. I'd expect:

protoc -I SourceFolder --csharp_out=SourceFolder/Classes 
SourceFolder/sample.proto

Jon


On Saturday, 7 May 2016 01:00:26 UTC+1, gurbhej...@pepperstone.com wrote:
>
> Dear Supoort,
> I am getting the compilation error when I try to generate the classes to 
> csharp with following commands.
>  protoc -I= SourceFolder --csharp_out= SourceFolder/Classes 
> SourceFolder/sample.proto
>  proton -proto_path= SourceFolder --csharp_out= SourceFolder/Classes 
> SourceFolder/sample.proto
>
> These commands don't work for csharp but works fine with --java_out.
>
> Anybody has any idea what might be wrong with these commands?
>
> Kind Regards
> Sandhu
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Timestamp.proto problem in c#

[Jon Skeet]

Timestamp is just a regular class - so you need to create a new instance 
before setting properties, e.g.

// Don't actually use this - see below.
test._timeStamp = new Timestamp
{
Seconds = DateTime.Now.Second,
Nanos = DateTime.Now.Second * 100
};

However, there are various things wrong with this:
- That will only give you a Seconds value in the range 0-59
- You're evaluating DateTime.Now twice, so you could get different values
- You're using DateTime.Now which is a *local* time; Timestamp is for 
global timestamps

Fortunately, there's a factory method to make all of this easy:

test._timeStamp = Timestamp.FromDateTime(DateTime.UtcNow);

On Friday, 9 September 2016 22:47:24 UTC+1, Uzair Saeed wrote:
>
> Hello,
>
> I have successfully compiled my .proto file with google.proto.Timestamp 
> and generated the .cs file with protoc. The only problem i am having is 
> initialization in my c# code.
>
> I have tried the following ,
>
> *.proto File*
>
> message teststamp{
>
> string Name = 1 ;
> string address = 2;
> google.protobuf.Timestamp _timeStamp = 3;
> }
>
>
> *C# File*
>
> teststamp test = new teststamp();
>
> test.Name = "Test";
> test.address = "Test_Test_TEST"
> //Example 2 : POSIX
> test._timeStamp.Seconds = DateTime.Now.Second;
> test._timeStamp.Nanos = DateTime.Now.Second*1000 ;
>
>
> The above is compiling without errors but giving me this error "Object 
> reference not set to an instance of an object" .I have tried few other 
> approaches but due to less help it is unable to fix the error. 
>
> Please help me out in this issue
>
> Thanks
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Reflecting Custom Options in Protobuf C#

[Jon Skeet]

Not imminently, I'm afraid. Pull requests welcome, of course, but I don't 
think it's high priority right now.

I've filed https://github.com/google/protobuf/issues/2143 to keep track of 
this.

Jon


On Monday, 19 September 2016 23:04:00 UTC+1, Teddy Zhang wrote:
>
> Looks like the custom options API is not exposed yet in 3.0. Is there any 
> plan to add that?
>
> On Friday, April 29, 2016 at 9:37:11 AM UTC-7, Jon Skeet wrote:
>
>> On Thursday, 28 April 2016 22:58:42 UTC+1, TravG wrote:
>>>
>>> I'm using Protobufs in C# and wondering how I can get access to custom 
>>> options I've annotated on a field at runtime via reflection.  I see some 
>>> indications that this should be possible:
>>>
>>
>> Hmm... I don't *think* we expose it at the moment. Will look into it. I 
>> don't want to expose the existing options protos for various reasons. Do 
>> you have a preferred API in mind? It's probably easiest to keep track of 
>> this as a Github feature request - are you happy to open one?
>>
>> Jon 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Protobuf c# with stomp

[Jon Skeet]

It's hard to know what's wrong when we can't see either the code or the 
error. It does sound very worrying if you're converting *binary* data into 
a string though. Are you doing anything to ensure the data is *safely* 
converted, such as using base64?

It would really help if you could post a short but complete example - or 
possibly ask on Stack Overflow, as that sounds more appropriate for this 
question.

Jon

On Thursday, 3 November 2016 00:06:34 UTC, Ganesh Shivshankar wrote:
>
> Hi, 
> I'm trying to use protof with stomp. We have a java server which is 
> running on a websocket over stomp. It uses protostuff 1.5.2. My client 
> needs to send the IMessage as a string to the server, where it gets 
> deserialized. I'm trying to do the below 
>
> IMessage.ToByteArray() 
>
> And then writing this to a stream reader and send the string as part of 
> the STOMP message to the server. 
>
> However the server keeps failing to deserialze it. I need to know what is 
> the correct way of doing it from the client side. Any help here is much 
> appreciated. 
>
> Cheers! 
> Ganesh

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Proto3 C# JSON parser throws error for wellknown types

[Jon Skeet]

Okay, I've tried it with your message - and it deserializes that JSON just 
fine for me. I've updated the issue - could you look there and reply to the 
questions?
(It would be better to keep it on github than on the mailing list.)

Jon


On Tuesday, 10 January 2017 08:03:48 UTC-5, Jon Skeet wrote:
>
> Thanks for reporting this - I've copied it into a github issue: 
> https://github.com/google/protobuf/issues/2574
>
> I'll look into it as soon as I can. (Although I'm at a conference this 
> week, making it slightly tricky.)
> I thought I had tests for all of the well-known types, so it's certainly 
> surprising...
>
> Jon
>
> On Tuesday, 10 January 2017 04:59:51 UTC-5, Ajay Bhandari wrote:
>>
>> Hi,
>> I have simple proto definition like below and through the protoc compiler 
>> I am able to use the generated C# message class to covert object to byte 
>> array, de-serialize the object from byte array using the message parser etc.
>>
>> When I try to use the JSON Formatter & parser, I am able to serialize the 
>> same to JSON string, but during deserialization the JSON parser throws an 
>> error about not able to convert System.UInt32 (.NET) to Google.
>>
>> Will appreciate any help in resolving this. I am using 
>> Google.Protobuf.3.1.0 and Google.Protobuf.Tools.3.1.0 nuget packages
>>
>> Thanks.
>>
>>
>> *PROTO=*
>> syntax = "proto3";
>> package testpack;
>> option csharp_namespace = "Test.v1";
>>
>> // import proto definitions from google protobuf
>> import "wrappers.proto";
>> import "timestamp.proto";
>>
>> message TestMessage {
>>  google.protobuf.UInt32Value testUintProperty = 1;
>>  google.protobuf.Int32Value testIntProperty = 2;
>>  google.protobuf.BoolValue testBoolProperty = 3;
>>  google.protobuf.Timestamp timestamp = 4;
>> }
>>
>>
>> *CODE SNIPPTES (C#)==*
>>  // this works
>>  var testMessage = > the generated TestMessage class>
>>  var tmBytes = testMessage.ToByteArray();
>>  var deserializedTestMessage = TestMessage.Parser.ParseFrom(tmBytes);
>>
>>  // this works - json below
>> JsonFormatter jsf = new JsonFormatter(new 
>> JsonFormatter.Settings(true));
>> string jsonString = jsf.Format(testMessage);
>>   
>>  // this throws error - see exception details below
>>  var deserializedTestMessageFromJson = 
>> JsonParser.Default.Parse(jsonString);
>>
>>
>> *JSON*
>> { "testUintproperty": 1024, "testIntproperty": 300, "testBoolproperty": 
>> true, "timestamp": "2017-01-10T09:46:53.218325200Z" }
>>
>>
>>
>> *SYSTEMEXCEPTION MESSAGE==*
>> Unable to cast object of type 'System.UInt32' to type 
>> 'Google.Protobuf.WellKnownTypes.UInt32Value'.
>>
>>
>> *STACK TRACE===*
>>  at lambda_method(Closure , IMessage , Object )
>>at Google.Protobuf.Reflection.SingleFieldAccessor.SetValue(IMessage 
>> message, Object value)
>>at Google.Protobuf.JsonParser.MergeField(IMessage message, 
>> FieldDescriptor field, JsonTokenizer tokenizer)
>>at Google.Protobuf.JsonParser.Merge(IMessage message, JsonTokenizer 
>> tokenizer)
>>at Google.Protobuf.JsonParser.Merge(IMessage message, TextReader 
>> jsonReader)
>>at Google.Protobuf.JsonParser.Parse[T](TextReader jsonReader)
>>at Google.Protobuf.JsonParser.Parse[T](String json)
>>at 
>> DeviceSimulator.Program.d__3.MoveNext() 
>> ...
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Proto3 C# JSON parser throws error for wellknown types

[Jon Skeet]

Thanks for reporting this - I've copied it into a github 
issue: https://github.com/google/protobuf/issues/2574

I'll look into it as soon as I can. (Although I'm at a conference this 
week, making it slightly tricky.)
I thought I had tests for all of the well-known types, so it's certainly 
surprising...

Jon

On Tuesday, 10 January 2017 04:59:51 UTC-5, Ajay Bhandari wrote:
>
> Hi,
> I have simple proto definition like below and through the protoc compiler 
> I am able to use the generated C# message class to covert object to byte 
> array, de-serialize the object from byte array using the message parser etc.
>
> When I try to use the JSON Formatter & parser, I am able to serialize the 
> same to JSON string, but during deserialization the JSON parser throws an 
> error about not able to convert System.UInt32 (.NET) to Google.
>
> Will appreciate any help in resolving this. I am using 
> Google.Protobuf.3.1.0 and Google.Protobuf.Tools.3.1.0 nuget packages
>
> Thanks.
>
>
> *PROTO=*
> syntax = "proto3";
> package testpack;
> option csharp_namespace = "Test.v1";
>
> // import proto definitions from google protobuf
> import "wrappers.proto";
> import "timestamp.proto";
>
> message TestMessage {
>  google.protobuf.UInt32Value testUintProperty = 1;
>  google.protobuf.Int32Value testIntProperty = 2;
>  google.protobuf.BoolValue testBoolProperty = 3;
>  google.protobuf.Timestamp timestamp = 4;
> }
>
>
> *CODE SNIPPTES (C#)==*
>  // this works
>  var testMessage =  generated TestMessage class>
>  var tmBytes = testMessage.ToByteArray();
>  var deserializedTestMessage = TestMessage.Parser.ParseFrom(tmBytes);
>
>  // this works - json below
> JsonFormatter jsf = new JsonFormatter(new 
> JsonFormatter.Settings(true));
> string jsonString = jsf.Format(testMessage);
>   
>  // this throws error - see exception details below
>  var deserializedTestMessageFromJson = 
> JsonParser.Default.Parse(jsonString);
>
>
> *JSON*
> { "testUintproperty": 1024, "testIntproperty": 300, "testBoolproperty": 
> true, "timestamp": "2017-01-10T09:46:53.218325200Z" }
>
>
>
> *SYSTEMEXCEPTION MESSAGE==*
> Unable to cast object of type 'System.UInt32' to type 
> 'Google.Protobuf.WellKnownTypes.UInt32Value'.
>
>
> *STACK TRACE===*
>  at lambda_method(Closure , IMessage , Object )
>at Google.Protobuf.Reflection.SingleFieldAccessor.SetValue(IMessage 
> message, Object value)
>at Google.Protobuf.JsonParser.MergeField(IMessage message, 
> FieldDescriptor field, JsonTokenizer tokenizer)
>at Google.Protobuf.JsonParser.Merge(IMessage message, JsonTokenizer 
> tokenizer)
>at Google.Protobuf.JsonParser.Merge(IMessage message, TextReader 
> jsonReader)
>at Google.Protobuf.JsonParser.Parse[T](TextReader jsonReader)
>at Google.Protobuf.JsonParser.Parse[T](String json)
>at 
> DeviceSimulator.Program.d__3.MoveNext() 
> ...
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: C# convert message data to byte array in protobuf encoding

[Jon Skeet]

Just use the ToByteArray extension method... although if the code you've 
shown is returning an empty array, I'd expect ToByteArray to do so as 
well...

On Tuesday, 21 March 2017 10:12:56 UTC, Matrix Guo wrote:
>
> using pb = global::Google.Protobuf;
> private static byte[] FormatToBinary(T obj)
>  { 
>using (MemoryStream stream = new MemoryStream())
> {   
> pb::CodedOutputStream s = new 
> pb::CodedOutputStream(stream);
> obj.WriteTo(s);
> //s.Flush();  //once I add it，the message could not be 
> sent any more
> return stream.ToArray();
> }
> }
>
> the result return an array with 0 element.
> once I add s.Flush(); the value will be changed,while the message could 
> not be sent any more.
>
>
> what I want to do is just converting message data to byte array in 
> protobuf encoding with proto3
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: How to Create Google.Protobuf.Collections.RepeatedField< T > with JSON formatter??

[Jon Skeet]

On Tuesday, 8 August 2017 08:06:47 UTC+1, LEE MONKEY wrote:
>
> Use funcation  toString() RepeatedField - > default JSON formatter.
> Then How to JSON formatter -> RepetedField OR IList??
>
>
> https://developers.google.com/protocol-buffers/docs/reference/csharp/class/google/protobuf/collections/repeated-field-t-
>

Looking at JsonParser, I don't think there's anything there at the moment - 
the intention is that JsonParser and JsonFormatter are really present so 
that you can parse/format whole messages, where repeated fields are just 
*part* of a message.

Now you could fake it up by creating a message which has a repeated field 
of the right type, add `{ 'field': ` to the start, then put your array 
JSON, then add `}` to the end, but that's a bit hacky.

Is there any reason you're serializing just the repeated field rather than 
a whole message? 

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: can I identify specific message type? c#

[Jon Skeet]

Messages don't contain any schema identification - they're just the data.

I suggest you create a new message containing a single field which is a 
"oneof" containing the other types. You can then create that "container" 
message and serialize it, always deserialize to that container message, and 
then identify which case was used.

Jon

On Thursday, 3 August 2017 14:33:55 UTC+1, Itay Pupko wrote:
>
> I'm new to protobuf, and I'm trying to convert JSON object into protobuf 
> messages in c#.
> My question is, my .proto file contain several messages types. is there a 
> way to find the messages type dynamically or my only shot is by trying all 
> possible options?
>
> I mean, if I know this is a Version message, then I simply write:
>  ver = encoder.Parse(data);
>
> but if it can be one of two options, like 'Version' and 'SysParams'
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: exchanging c# protobufs with native (c++) code with minimal performance hit

[Jon Skeet]

No, the in-memory representation of a C# message is in no way related to 
the serialized representation.
If your C++ code is just sending the serialized protobuf though, I don't 
think you'd need to deserialize in the C++ code - just serialize in C#, 
pass the byte array to the C++ code, and get that to send it directly.

(This is what gRPC does, for example.)

On Sunday, 28 May 2017 22:23:15 UTC+1, Mike Bennett wrote:
>
> Hi -- I have a C++ library which sends protobuf messages over the network 
> and I'd like to
> provide a C# wrapper that allows the client application the ability to 
> generate a protobuf,
> pass it to native code and have the native code consume it directly.
>
> Is the C# 'at rest' representation of a protobuf message compatible with a 
> C++ layout
> of the same message? That is, if I've created C# code that built a 
> protobuf message,
> can I directly pass it somehow to C++ as a protobuf (if I could get the 
> raw byte pointer
> to the message), or do I have to first serialize it to a buffer, pass the 
> serialized buffer
> to C++ then deserialize it in C++?
>
> I'd really like to avoid the deserialization/serialization on either side 
> of the C#/C++
> boundary for performance.
>
> Thanks for any information or pointers!
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Inconsistent Merge Behavior

[Jon Skeet]

It's a bug, basically. We probably haven't noticed it before because 
merging is significantly rarer than parsing from scratch or serializing.

I've filed https://github.com/google/protobuf/issues/3200

Jon

On Thursday, 8 June 2017 09:26:09 UTC+1, Ron Ben-Yosef wrote:
>
> We've been using proto3 at my workplace for a while now, and noticed some 
> inconsistency in the merge behavior between the C++ and C# implementations 
> when it comes to oneof fields.
> It seems that in the C++ implementation, if both messages being merged 
> have the same oneof case set then the field is merged properly (otherwise 
> the incoming message's field replaces the existing one).
> On the other hand, in the C# implementation the incoming message's field 
> always simply replaces the existing one, even if it's the same field (as 
> opposed to proper merging if it's the same field, as in the C++ 
> implementation).
> It looks like this is true for the merge functions both in the generated 
> code and in the protobuf libraries.
>
> Is there any reason for the different behaviors? Is there any change 
> planned to make the two implementations' behaviors more consistent?
> I think the C++ behavior probably makes a little more sense, but either 
> way - shouldn't this behavior be consistent between the different 
> implementations?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] Null String in C# (CheckForNull)

[Jon Skeet]

Exactly. In an early implementation I treated null and empty string as the 
same - but it ends up being weird in all kinds of ways. (Either setting a 
property and then fetching it isn't a roundtrip, or serializing and 
deserializing isn't a roundtrip.)

In the end, I went with "stick to protobuf semantics: every string has a 
value, which is empty by default."

If you use the StringValue wrapper type, you then *can* use null, which 
means "there's no StringValue here".

On Tuesday, 3 October 2017 22:06:26 UTC+1, Marc Gravell wrote:
>
> Fields are optional but the implicit default for a string is a zero length 
> string, not a null length string. To be honest, either approach seems 
> perfectly reasonable as long as it is documented and any exception is clear 
> and obvious. For my separate implementation I chose to interpret nulls as 
> "meh, not set, ignore it", but... either is fine IMO.
>
> On 3 October 2017 at 19:35, Everton Araujo  > wrote:
>
>> Hi all,
>>
>> I'm facing the situation where a string value is not allowed to be null 
>> in Protobuf 3 using C# (CheckNotNull).
>> I do not understand it considering that fields are optional by default in 
>> proto3.
>> Does anyone knows the original reason for this constraint? As far as I 
>> could see, it happens for string and bytearrays.
>>
>> Regards,
>>
>> Everton
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Protocol Buffers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to protobuf+u...@googlegroups.com .
>> To post to this group, send email to prot...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/protobuf.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Regards, 
>
> Marc
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: C# field length

[Jon Skeet]

You can't do that. You can have fixed0length 32-bit integers - but there's 
still the field tag first.
For strings, the wire format is a field tag, followed by the data length, 
followed by the data - where the data is the UTF-8-encoded version of the 
string.

You could have a bytes field and document that it should always be 40 
bytes, but again you'd still have the field tag and the data length first.

Basically, if you're going to use Protobuf, you need to work with the 
Protobuf wire format - whereas it sounds like you have a different wire 
format you need to conform to.

Jon


On Wednesday, 23 August 2017 21:50:14 UTC+1, Ben-adi Ben-Adi wrote:
>
> Hi, I'm new to protobuf and wanted to know:
> Lets say that I have a message that contains 2 fields:
> int num (with the length of 2 bytes )
> string str (with the length of 40 bytes )
>
> the lenght of the message must be 40+2=42 bytes exactly
>
> what is the why to define such message in .proto file??
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: ProtoBuf 3 C# Options

[Jon Skeet]

C# protobuf doesn't support proto2, which all of the descriptor aspects are 
based on.

We've included minimal support for fetching options at the moment - just 
enough so it's *possible*. But yes, it's far from as clean as it could be.
Rather than just exposing the constants, I'd rather revisit how options are 
exposed entirely - which should also be done in the light of the 
possibility of supporting proto2 completely (as per this issue 
).

Basically, it's a matter of being very conservative about the API we 
expose. That's painful in the short term, but better in the long term.

Jon

On Saturday, 5 May 2018 00:56:41 UTC+1, Jeremy Swigart wrote:
>
> Anyone know why generated C# classes don't include the named constants for 
> options? (MessageOptions,FieldOptions,etc).
>
> They still work but you have to hard code the number value directly, which 
> is less that readable and isn't on par with the named constants generated 
> for the C++ files.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] Where is Protocol Buffers wire level specification?

[Jon Skeet]

On Thursday, 7 June 2018 10:59:34 UTC+1, Markus Schaber wrote:
>
> This text is missing some interesting aspects, e. G. what happens when the 
> field number needs more than 5 bits (I cannot imagine it's limited to 31 
> fields per message).
>

No, that's already described:

> Each key in the streamed message is a varint with the value (field_number 
<< 3) | wire_type – in other words, the last three bits of the number store 
the wire type.

And slightly earlier there's a description of how varints are serialized. 
So if you have a field number of (say) 1000 and a wire format of 1, that 
tag would be serialized as the varint encoding of the number 8001, which is 
(1000 << 3) | 1.

Jon

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Any way to stop rename field in codegen?

[Jon Skeet]

On Thursday, 8 March 2018 11:41:28 UTC, ke ren wrote:
>
> I am trying to migrate our project to protobuf and find one annoying 
> feature in protobuf c# codegen. It will automatically rename the field name 
> defined in proto during codgen to fit camel convention. For 
> example, NURBSSurface will be renamed to Nurbssurface, XRay to Xray etc. It 
> causes big naming changes in code and back compatibility issue with old 
> data format which is field name case senstitive. Is there any way to stop 
> codegen renaming?
>

No, that's not configurable. (It was in my original proto2 port, but we 
reduced the set of options for the proto3 version for simplicity.)

For some cases, just changing the protobuf field name  would work, e.g. 
x_ray will create a property called XRay. You probably don't want a field 
called n_u_r_b_s_surface though...

Jon

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Any way to stop rename field in codegen?

[Jon Skeet]

On Thursday, 8 March 2018 13:51:45 UTC, ke ren wrote:
>
> Thanks to confirm it. will JsonParser use pbr::OriginalName or the field 
> name in generated class for json deseriliazation? If it uses the field 
> name, probably it would work. Otherwise, probably have to consider data 
> deser bridge or something.
>

The JSON parser will use the json_name part from the descriptor:
https://github.com/google/protobuf/blob/master/csharp/src/Google.Protobuf/Reflection/FieldDescriptor.cs#L100
https://github.com/google/protobuf/blob/master/src/google/protobuf/descriptor.proto#L211

That can be set on a per-field basis with the json_name option, so that may 
help you.

Jon

 

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: proto file contains fields beginning with an underscore

[Jon Skeet]

This looks like issue 8101 
, which was fixed 
very recently (PR 10268 
).  Unfortunately I 
don't believe it's been included in a release yet, but you could fetch the 
latest code to build a version of protoc with the fix, or temporarily 
manually patch the generated code to add an underscore (so _400Url and 
_400Url_).


On Thursday, 11 August 2022 at 14:15:28 UTC+1 wulun00 wrote:

> I tried to convert a proto file that contains fields beginning with 
> underscores to a c# file, but it cannot be converted to the correct CS file
> example:
> msg.proto
> syntax = "proto2";
> message Msg {
>   optional string _400Url = 1;
> }
>
> Msg.cs 
> /// Field number for the "_400Url" field.
> public const int 400UrlFieldNumber = 1;
> private readonly static string 400UrlDefaultValue = "";
>
> private string 400Url_;
> [global::System.Diagnostics.DebuggerNonUserCodeAttribute]
> [global::System.CodeDom.Compiler.GeneratedCode("protoc", null)]
> public string 400Url {
> get { return 400Url_ ?? 400UrlDefaultValue; }
> set {
> 400Url_ = pb::ProtoPreconditions.CheckNotNull(value, "value");
> }
> }
>
> Unable to compile because of 400Url
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/protobuf/9f73b9de-8d02-4eb7-82ba-bd35a1071e2an%40googlegroups.com.

Re: Performance comparison of Thrift, JSON and Protocol Buffers

[Jon Skeet sk...@pobox.com]

On Mar 2, 10:14 am, Adewale Oshineye adew...@gmail.com wrote:
 This article has some surprising results from it's performance
 comparison of Thrift,  Protocol Buffers and 
 JSON:http://bouncybouncy.net/ramblings/posts/thrift_and_protocol_buffers/

More specifically, it's comparing the performance of the Python
implementations of all of those. That only really says that our Python
implementation is relatively slow. I think the numbers for C++/Java
are somewhat better :)

Jon

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: protocol buffers in .net

[Jon Skeet sk...@pobox.com]

On Mar 2, 9:35 pm, Marc Gravell marc.grav...@gmail.com wrote:
 I'm pretty happy with ongoing general maintenance, but with Jon
 working for Google, and it being a closer port of the existing
 implementations... I'd realistically expect things may be a little
 stacked in favour of that one.

I hope that working at Google wouldn't be a significant factor - but I
think the closeness of the port is. Basically it would mean that if
someone downloaded just the main distribution, they could use a very
similar API in C++, Java and C# (and Python? I don't know how close
the API is there).

In a similar vein, a change in Google's Java code currently prompts me
to change the C# code (I recently caught up in terms of
Message.toBuilder and nullity checks, for example).

There's one major blocker at the moment though: all my copies of the
Google test .proto files are decorated with the C# options. *At the
moment* that means the Java and C++ code would have to build the C#
options as well. I'm looking into adding something to the import
syntax so that an import could be marked as options only which would
mean that the types within it could only be used when applying options
(rather than defining fields) but the import wouldn't be in the list
of dependencies. At that point, the C# options could be applied
harmlessly in terms of the Java/C++. (If anyone has any better
suggestions for getting round this, I'm all ears.)

There's also the matter of working out how the C# port would end up
getting built - I currently use NAnt/MSBuild, and my make knowledge is
very limited. That's a relatively minor issue though.

In short, I don't think that integration would be appropriate right
now, but I'd be happy for it to happen some time in the future. I
think we'd have to work out what the tangible benefits and costs would
be though.

 Even if that comes to pass, I'll still maintain protobuf-net anyway,
 simply because it seems useful to a reasonable number of people ;-p

I'd be shocked and disappointed for you to say anything else :) We
must port my benchmark test to protobuf-net at some point...

Jon


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Performance comparison of Thrift, JSON and Protocol Buffers

[Jon Skeet sk...@pobox.com]

On Mar 3, 7:37 pm, Dave Bailey d...@daveb.net wrote:
 Thanks for writing this up; I think it's a nice real world example.

 I ran an equivalent test (using your same .proto files) in Perl to
 compare JSON::XS, protobuf-perlxs, and Storable.  I did this on an
 x86_64 quad-core Xeon (2.5 GHz) and found:

 1) Your original dns.proto (with strings), serializing and
 deserializing a DnsResponse with 5000 random DnsRecord elements:

snip

Could I ask you to keep hold of the .proto files and generated files?
I'm hoping to commit the Java version of my C# benchmark code on
Thursday... it would be nice to have more data.

Jon


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: protocol buffers in .net

[Jon Skeet sk...@pobox.com]

On Mar 3, 11:06 pm, Kenton Varda ken...@google.com wrote:
 sk...@pobox.com wrote:
  There's one major blocker at the moment though: all my copies of the
  Google test .proto files are decorated with the C# options. *At the
  moment* that means the Java and C++ code would have to build the C#
  options as well. I'm looking into adding something to the import
  syntax so that an import could be marked as options only which would
  mean that the types within it could only be used when applying options
  (rather than defining fields) but the import wouldn't be in the list
  of dependencies. At that point, the C# options could be applied
  harmlessly in terms of the Java/C++. (If anyone has any better
  suggestions for getting round this, I'm all ears.)

 You could also just fork those files.

Well, the files are effectively forked now. But there's a bigger issue
- I don't want the C# options to force anyone to generate C++ and Java
files if I can help it. It'll only get worse if different languages
add their own options. Imagine in 5 years - an open source project
comes out with a .proto file with support for 5 languages. Suddenly
your Java code has dependencies on Perl options, Python options, C#
options, Ruby options etc. Ick.

Anyway, I'll experiment for a while and report when I get back.

  There's also the matter of working out how the C# port would end up
  getting built - I currently use NAnt/MSBuild, and my make knowledge is
  very limited. That's a relatively minor issue though.

 Well, currently we only use make for C++.  Java uses Maven, Python uses
 setuptools.  Every language seems to have their own favorite
 ostensibly-language-independent build system.

:) I've spoken to the Mono folks recently and apparently the C# port
*very nearly* builds now on Mono - I'm going to try to get that
working very soon. I'd really like to be able to give perf figures for
both .NET and Mono.

Jon


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Initial benchmarking committed to svn (r100)

[Jon Skeet sk...@pobox.com]

On Mar 5, 11:47 am, ijuma isma...@gmail.com wrote:
  I haven't optimised with a profiler very recently - I suspect there
  are some improvements which could be made by skipping the null
  handling when merging/parsing (as it should be unnecessary). I didn't
  use any particular options when running the Java version (1.6.0_11-
  b03) so I'm sure there are tweaks to be made there too.

 Before any other settings are tried, it would be worth benchmarking it
 with -server as it can make a large difference when compared to -
 client. The default varies based on OS and machine specification so it
 makes sense to use an explicit setting to make it clear what JIT was
 used.

Right. Somewhat embarrassingly, this laptop doesn't actually *have*
the server JIT installed. I'm mostly working on the C# code at the
moment, but I'll come back and rerun the test with the server JVM when
I've got a bit more time.

Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: optimize_for option default

[Jon Skeet sk...@pobox.com]

On Mar 5, 11:39 pm, Kenton Varda ken...@google.com wrote:
 As you know if you've read the docs carefully, when using C++ or Java
 protocol buffers, for best performance you need to add a line to your .proto
 files:

   option optimize_for = SPEED;

snip commentary

I think there are three issues here:

1) Yes, it's really easy to miss that. Shortly after PBs were released
I saw a blog post showing how slow PBs are - and then I pointed out
the optimize_for option...
2) It's a pain to have to use a whole different .proto file just to
specify this option. While I believe many options *should* be in
the .proto file (particularly where they might affect individual
fields etc) I think this would make sense to have as a compiler/
generator flag (it could be in either place, for situations where the
two are split). For instance, you may have a memory-limited client
where speed doesn't matter, and a memory-rich server processing
gazillions of these things - they should be able to use the
same .proto file.
3) Backward compatibility.

I suspect we could really do with the compiler working in four
different modes:

1) Default to SPEED when otherwise undefined; obey proto file
otherwise
2) Default to CODE_SIZE when otherwise undefined; obey proto file
otherwise (current mode)
3) Generate code using SPEED regardless of proto file
4) Generate code using CODE_SIZE regardless of proto file

I think it would we should at least be able to specify I want the old
behaviour on the command line just because that makes the backward
compatibility story easy: use this argument and it's all as it was -
but I'd be happy for the actual default to be changed.

(Evil thought: make the default a build-time setting for the compiler
itself, so if you want to build protoc with the old behaviour you can.
Almost certainly not a good idea, but it's amusing to think of the
number of places this *could* be set...)

Jon

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Initial benchmarking committed to svn (r100)

[Jon Skeet sk...@pobox.com]

On Mar 6, 1:24 pm, Justin  Azoff justin.az...@gmail.com wrote:
 On Mar 6, 1:13 am, Justin  Azoff justin.az...@gmail.com wrote: I did a 
 quick port to python(pasted at the end, hopefully it wont be
  garbled)

 well, that didn't work.
 I threw it up athttp://bouncybouncy.net/ramblings/files/ProtoBench.py
 if anyone is interested.

Sounds like a good thing to include in svn, if you're happy with the
licensing of it etc. The more languages we can benchmark, the
better :) (I'd be really interested in seeing the C++ results, but
I've no idea how the reflection side of things would work, if at all.
I'm not a C++ person...)

Kenton, who's our most Python-aware committer?

Jon

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: optimize_for option default

[Jon Skeet sk...@pobox.com]

On Mar 6, 2:23 pm, aepensky apen...@gmail.com wrote:
 +1 for making it a compiler command-line option.

 Pretty much all other IDLs get this wrong to some degree also.
 Having annotations or options in the IDL file is nice, but make sure
 they are only helping to define the message and the service, not the
 implementation.
 When I get a service definition from a service author I don't want to
 be told how to optimize, or what namespace my generated classes should
 go into.
 Those things can be different for every client.  As it is now, a
 client developer would have to mark up the .proto file that s/he
 received from the service developer.

Obviously I agree about the optimisation, but why the namespace?
Surely the provider of the proto owns which namespace it should be
in, don't they?

Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: optimize_for option default

[Jon Skeet sk...@pobox.com]

On Mar 6, 4:55 pm, aepensky apen...@gmail.com wrote:
 Sorry, I realize that wasn't a very clear statement...

 What I mean is, if there is an option which does not leave any
 fingerprint in either the serialized message or the
 FileDescriptorSet, so that you can't tell how the option was set by
 looking at either of these, then the option is controlling only code
 generation and is not affecting the service contract.  So it should
 not be in the .proto file.

 I think that applies to the package statement as well as
 optimize_for.  Protocol Buffers does not put globally unique
 signatures into the messages or descriptors based on your package
 declaration.  It only affects the code generation.

It's definitely in the descriptor set - because that's what my C#
generator uses!

I agree that it doesn't affect the wire format of the messages
themselves, but I still think a world in which everyone who uses the
same package/namespace for the same proto for each language is a saner
one. (i.e. all Java users will see one package; all C# users will see
one namespace, etc. There can be differences between languages, but at
least two users of the same language have a common namespace).

It's certainly a personal thing, and again maybe you should be able to
*override* it from the command line, but I think it makes sense to at
least put default package/namespace options into the proto file.

Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Streaming different types of messages

[Jon Skeet sk...@pobox.com]

On Mar 27, 1:32 pm, achin...@gmail.com wrote:
 If I understand correctly there is no good way to use proto buffers to
 stream different types of messages, right? For example if my stream
 has a mix of several messages of type m1 and m2, I will have to device
 a scheme outside of proto buffers to separate it into 2 streams and
 then pass it through parsers for each.

 In other words is there a way to do event based parsing using proto
 buffers, or even a way to say don't parse a repetitive field unless
 needed.

No, you don't have to do it into separate streams. Instead, stream a
sequence of messages each of which has either an m1, or an m2, or an
m3 etc. This basically ends up being (tag) (message) (tag) (message),
where the tag is effectively identifying the type of message.

All you need to do is create the wrapper message, and the rest should
work fine.

Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Protocol Buffers Vs. XML Fast Infoset

[Jon Skeet sk...@pobox.com]

On Apr 3, 10:40 am, ShirishKul shirish...@gmail.com wrote:
 I worked to see the difference between the *XML fast infoset* and the
 *Protocol Buffers* (although I'm not aware about what are internal
 things happening therein).

 I found that for a typical data to be transferred across the wire for
 size of 500KB that a XML file would represent has corresponding file
 size as 300KB for PB binary and around 130KB for XML Fast Infoset
 binary file.

Just going back to these numbers, a less-than-50% benefit for going
from XML to PB is surprisingly bad.

Do you have a sample file with non-confidential data that we could
look at?

Jon


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Performance comparison of Thrift, JSON and Protocol Buffers

[Jon Skeet sk...@pobox.com]

On Apr 18, 4:23 am, TimYang iso1...@gmail.com wrote:
 Alkis is quite right, sorry for the typo.

Which JIT were you using, by the way? I found that using the -server
option made the Java ProtoBuf code run more than twice as quickly. Of
course, it could be that the Thrift code would get the same boost...

Jon


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Immutability of generated data structures

[Jon Skeet sk...@pobox.com]

On Apr 23, 1:03 pm, Kannan Goundan kan...@cakoose.com wrote:
 The code generated by protoc seems to go to great lengths to make sure
 that once a message object is created, it can't be modified.  I'm
 guessing that this is to avoid cycles in the object graph, so that the
 serialization routine doesn't have to detect cycles.  Is this
 correct?  Would a cycle in the object graph put the current serializer
 into an infinite loop?

I think it's more because our experience in Google is that immutable
objects are easier to reason about - basically a lesson from
functional programming.

But yes, I suspect the side-benefit of preventing cycles is a
generally good thing too :)

Jon
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@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: Report a bug

['Jon Skeet' via Protocol Buffers]

Right - will do that, yes.

On Monday, 22 February 2016 02:46:28 UTC, ykwd.t...@gmail.com wrote:
>
> Thank you for your kind answer to my stupid question. I successfully 
> compile it now.
>
> I have installed both vs2013 and vs2015. Since the 2nd line in the .sln 
> file says "# Visual Studio 2013", the vs version selector automatically 
> start vs2013 to open this project. One can either mannually select vs2015 
> to open it,  or change this line to "# Visual Studio 2015" to automatically 
> use vs2015 each time.
>
> On Saturday, February 20, 2016 at 10:40:21 PM UTC+8, Jon Skeet wrote:
>>
>> In general, you'd report a bug at 
>> https://github.com/google/protobuf/issues
>>
>> ... but in this case there's no bug. This is perfectly valid C# 6, which 
>> is required to build the Google.Protobuf library.
>> The code generated by protoc *doesn't* use C# 6, so you should be fine 
>> with whatever you generate, and the fact that the library uses C# 6 won't 
>> stop the compiled code from being used by older versions of Visual Studio 
>> etc.
>>
>> Basically, we require Visual Studio 2015 (or the equivalent version of 
>> the Mono compiler) for Google.Protobuf itself.
>>
>> Jon
>>
>> On Friday, 19 February 2016 23:57:10 UTC, ykwd.t...@gmail.com wrote:
>>>
>>> Hi, 
>>>
>>> Protobuf is a nice work which saves me a lot of time.
>>>
>>> Through my using, I find a bug as the following : 
>>>
>>> In some csharp source files such 
>>> as csharp/src/Google.Protobuf/Reflection/FieldDescriptor.cs, there are some 
>>> codes like :
>>>
>>> throw new DescriptorValidationException(this, $"\"{Proto.TypeName}\" is 
>>>> not an enum type.");
>>>
>>>
>>> or 
>>>
>>> string IDescriptor.FullName => Name;
>>>
>>>
>>> It seems that this is due to mistakes in automatic code generation.
>>>
>>> These codes cause the csharp project building failed.
>>>
>>> This bug first occurs at the submission of 
>>>  72ec33676fd40ccfe719ace162fcf859ae9251bc.
>>>
>>> I don't know if this is the right place to report bugs. I'm sorry if 
>>> not, can anyone tell me how to report it.
>>>
>>> Thanks.
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Proto compiler is for win-32

['Jon Skeet' via Protocol Buffers]

I don't know the details of the C++ side of things, but Java and C# will be 
absolutely fine. The generated code doesn't care about architecture, and 
the Google.Protobuf assembly is AnyCPU.

Jon

On Tuesday, 10 May 2016 23:52:05 UTC+1, Techie suk wrote:
>
> I installed the compiler for protocol buffer from this website: 
>
> https://developers.google.com/protocol-buffers/docs/javatutorial#defining-your-protocol-format
>
> I am writing client code in Java, C++, C# languages. JDK and .net versions 
> are 64-bit. will compiling proto with 32-bit cause a problem?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: why does uint64, fixed64 map to string when converted to JSON

['Jon Skeet' via Protocol Buffers]

On Monday, 18 July 2016 18:25:41 UTC+1, Shashwat Agarwal wrote:
>
> I was looking at this document: 
> https://developers.google.com/protocol-buffers/docs/proto3#json and 
> noticed that int64, fixed64, uint64 are mapped to string when converting to 
> JSON. Any specific reason why this is done? This deviation breaks a lot of 
> other JSON parsers and any code in JS that relies on the fact that *int64 
> are numbers rather than string. 
>

It's due to the way that all numbers in JSON are basically IEEE-754 64-bit 
doubles... which means that any 64-bit integers can lose information. Using 
a string instead, all 64-bit integers can be round-tripped with no loss of 
information.

Jon
 

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] GPB Beta 3: Case for C# Enum case

['Jon Skeet' via Protocol Buffers]

On 11 July 2016 at 19:33, Arthur Griffith 
wrote:

> I completely understand the desire to follow a convention, but ill make
> some arguments here
>
>- *C# conventions are not strong. *This is a bit of a 'musing', but I
>have found that C# developers do not tend to follow a single standard, most
>probably because there is no official standard. Notice the initial
>requester even suggests Pascal OR camel case for enums. I even believe
>different editors enforce the standards differently.
>
> I would very strongly disagree with this - while I would say that C#
developers have multiple standards for *private* members, the conventions
for *public* members are pretty much universally used in my experience. Not
only the whole MS framework, but just about every reputable open source
framework follows the same conventions.

My own experience (and feedback from the team) is that it's *much* nicer to
use enums now that it was before. It feels properly idiomatic.

>
>- *Programmer Choice. *Even the initial suggestion that was linked
>suggests adding it as an option.
>
> I think there is an argument to be made to allow the programmer to choose. In
> my case, I have several hundred enums that are actually being used to
> define classes to be loaded reflectively. So to me, the enum names are
> significant.
>

There was discussion on this internally, and the decision was for this not
to be an option in the long run.

Note that this isn't so very different to what we're doing elsewhere - the
property/method names are adjusted to the idiom of the language, for
example.

Jon

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] Generating C# Code from Proto file into multiple code files not inline with file for each type, It should inline with file it imports

['Jon Skeet' via Protocol Buffers]

On Tuesday, 15 November 2016 21:20:01 UTC, venkatesu punugupati wrote:
>
> Thanks for the response..
> Let me add more details to get clear..
> A.proto , B.Proto are two proto files
> B.proto imports A.proto then if generate the code then you will get B.cs 
> containing all the types present A also in the same file.
>

No, that's not true. B.cs will only contain the types declared in B.proto.
 

> But i like to have A.cs as separate file and B.cs as separate file but 
> B.cs refers the types present in A.cs  
>

And that's what already happens.

If you're seeing something else, then please:

- Give a complete example, with two proto files and the exact command line 
you're using to generate the code
- Make sure you're using the code related to this repository - there are a 
few other C# protobuf ports around

Jon

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] Generating C# Code from Proto file into multiple code files not inline with file for each type, It should inline with file it imports

['Jon Skeet' via Protocol Buffers]

Sorry - "this repository" was vague - I 
meant https://github.com/google/protobuf

The corresponding NuGet packages are Google.Protobuf and 
Google.Protobuf.Tools.

Jon

On Wednesday, 16 November 2016 07:04:06 UTC, Jon Skeet wrote:
>
> On Tuesday, 15 November 2016 21:20:01 UTC, venkatesu punugupati wrote:
>>
>> Thanks for the response..
>> Let me add more details to get clear..
>> A.proto , B.Proto are two proto files
>> B.proto imports A.proto then if generate the code then you will get B.cs 
>> containing all the types present A also in the same file.
>>
>
> No, that's not true. B.cs will only contain the types declared in B.proto.
>  
>
>> But i like to have A.cs as separate file and B.cs as separate file but 
>> B.cs refers the types present in A.cs  
>>
>
> And that's what already happens.
>
> If you're seeing something else, then please:
>
> - Give a complete example, with two proto files and the exact command line 
> you're using to generate the code
> - Make sure you're using the code related to this repository - there are a 
> few other C# protobuf ports around
>
> Jon
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Json Program to Protobuf

['Jon Skeet' via Protocol Buffers]

It's not really clear to me what exactly the problem is, or what the server 
is expecting. Are you just trying to make a POST request with the body as a 
byte array? If so, that shouldn't be too hard - just call ToByteArray on 
the message, and then use that as the body of the request...

Have you already set up the server to receive protobuf requests? It won't 
just happen out of the box, without you configuring your server to handle 
it.

Jon

On Thursday, 10 November 2016 23:59:42 UTC, JAlsi wrote:
>
> Hello,
>
>
> I'm very new in developing with Protobuf.
>
> I did read the tutorial and after that I am able to create the .proto 
> files.
>
> Now the main problem.
>
> I have created a program in C#, which did send requests to a web APi on 
> our Server (http://url/api/car?id=1?format=json )
> Now, I want to use protobuf because it is much faster, but I don't know 
> how to connect the createt Classes (out of the protoFiles) to the APi.
> I know that I have to set the header to x-protobuf.
>
>
> Can someone show me, how to do a simple request ?
>
>
>
> Thanks!
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[protobuf] Re: Parser error in java or C# save to binary

['Jon Skeet' via Protocol Buffers]

Could you create a minimal example, with relevant C# and Java code? I very 
much doubt this is a bug, and I suspect that in trying to reproduce it 
you'll find out what's wrong, but if not, we'll be in a much better 
position to fix it.

Jon

On Thursday, 30 March 2017 14:56:06 UTC+1, Андрей Баранов wrote:
>
> message Msg_Order
> {
> message Msg_OrderItem
> {
> int32 item_id = 1;
> int32 count = 2;
> int32 price = 3;
> Msg_Item item = 4;
> }
> int32 id = 1;
> map order_items = 2;
> int32 amount = 3;
> Int64Value dt_create = 4;
> int32 state = 5;
> string payment_id = 6;
> }
>
> When I parse in Java Msg_Item item = 4; is empty !!!
> BUT !!! When I convert
> from map order_items = 2;
> to
> repeated Msg_OrderItem order_items = 2;
>
> it begins work  BUG ???
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

Re: [protobuf] Why is an InvalidCastException being thrown when deserialzing a well-known type using the proto3 JSON parser?

['Jon Skeet' via Protocol Buffers]

Okay, there are two pieces of good news:

   - I've managed to reproduce the issue
   - It's easy for you to fix by changing your proto and how you build

Basically, you're not importing the wrapper types as in the way protoc
expects.

Instead of importing "wrappers.proto" and using -I on the command line to
point to google/protobuf, you should import
"google/protobuf/wrappers.proto" and use -I to point to the directory above
google (in the protobuf tools package, which is where I assuming you're
finding wrappers.proto) You can then refer to just "Int32Value" instead of
".google.protobuf.Int32Value", although the latter still works too.

At that point, your NullableInt property should be generated as a .NET
Nullable rather than as an Int32Value, so you need to change your code
to:

var foo = new Foo { NullableInt = 5 }


It should be much easier to work with at that point, aside from anything
else.

It turns out you're not the first person to run into this:

   - https://github.com/google/protobuf/issues/2574
   - https://github.com/google/protobuf/issues/2575

... but it's still not clear to me whether we *should* try to fully support
the way you were generating the code before; it's entirely possible that
other parts of protobuf infrastructure will be confused by this too. I can
look at fixing this particular part of the C# codegen, but I wouldn't like
to say it'll be plain sailing for everything else.

Jon


On 24 October 2017 at 21:56, Adam Cozzette <acozze...@google.com> wrote:

> +Jon Skeet, who is the expert on C# protos
>
> On Mon, Oct 16, 2017 at 7:41 AM, <david.razzetti...@btinternet.com> wrote:
>
>> Using Google.Protobuf Nuget package version 3.4.1
>>
>> In its simplest form, I have a Google protocol-buffers message defined
>> like this:
>>
>> syntax = "proto3";package tests;
>> option csharp_namespace = "MyTests";
>> import "wrappers.proto";
>>
>> message Foo {
>> .google.protobuf.Int32Value NullableInt = 1;}
>>
>> I compile it to C# code using Google's protoc tool from
>> Google.Protobuf.Tools version 3.4.0.
>>
>> When I instantiate an instance of Foo and serialize it to a string using
>> the Google.Protobuf.JsonFormatter I get a sensible result, which is "{
>> "NullableInt": 5 }". When I de-serialize this back into a Foo instance
>> using Google.Protobuf.JsonParser, the parser throws a
>> System.InvalidCastException stating "Unable to cast object of type
>> 'System.Int32' to type 'Google.Protobuf.WellKnownTypes.Int32Value'."
>>
>> Why is this exception being thrown? Am I doing something stupid?
>>
>> Here is the code that I am running:
>>
>> [Test]public void TestRoundTripInt32Value(){
>> var foramtter = new JsonFormatter(new JsonFormatter.Settings(false));
>> var foo = new Foo { NullableInt = new Int32Value {Value = 5} };
>> var str = foramtter.Format(foo);
>> Console.WriteLine(str);
>> var parser = new JsonParser(new JsonParser.Settings(100));
>> var foo2 = parser.Parse(str);  // <= Throws!
>> Assert.That(foo2, Is.EqualTo(foo));}
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Protocol Buffers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to protobuf+unsubscr...@googlegroups.com.
>> To post to this group, send email to protobuf@googlegroups.com.
>> Visit this group at https://groups.google.com/group/protobuf.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.