Re: License changing to BSD.

(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

Re: Status of C# Projects?

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

Options in 2.0.2 broken?

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

Re: Options in 2.0.2 broken?

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

Re: Add .net support

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

Re: C# port has new layout

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

Re: Status of C# Projects?

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

Re: Status of C# Projects?

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

Adding options without adding dependencies

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

Re: adding languages to protoc

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

Re: Streaming

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

Re: 2.0.3 officially released

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

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

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

Re: State of protobuf for C# ?

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

Re: Additional testing file

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

Re: Additional testing file

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

Initial benchmarking committed to svn (r100)

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

C# port status update

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

Re: Python C Implementation - Update Request

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

Re: C# port status update

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

Re: Suggestion for improving WriteDelimited/ParseDelimited

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

Re: speed option for code generation

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

Re: Suggestion for improving WriteDelimited/ParseDelimited

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,

Re: ANN: protobut-net with VS2008 support

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

Re: Lite mode is in SVN -- mostly

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

Re: Can't seem to make Extension parsing working...

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

Re: Can serialized messages be used reliably as keys?

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

[protobuf] Re: Regd: How do I represent java.util.Date in my .proto definition?

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

[protobuf] Re: Error parsing from InputStream

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

[protobuf] ByteString hash code... would anyone expect it to be portable?

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:

[protobuf] Re: ByteString hash code... would anyone expect it to be portable?

: 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

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

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

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

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

[protobuf] C# port: new version available (v0.9.1)

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

[protobuf] Re: How to use Protocol buffers in visual studio c#.net

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

[protobuf] Re: building .proto files from Visual Studio 2010 for C#

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

[protobuf] Re: Plans to support C#?

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] Re: Plans to support C#?

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

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

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:

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

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

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

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 t

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

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

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

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

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

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

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

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

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

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

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

eem 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

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

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

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

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

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

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

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

t; 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 Skee

[protobuf] Re: C# Enum Flags

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

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

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

[protobuf] Re: Report a bug

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

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

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 m

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

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

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

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

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

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

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

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

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

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

[protobuf] Re: photo file compilation Error for csharp

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:

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

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

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

ptions 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

[protobuf] Re: Protobuf c# with stomp

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

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

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

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

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

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

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)

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

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

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

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

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

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

[protobuf] Re: Inconsistent Merge Behavior

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

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

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

[protobuf] Re: C# field length

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

[protobuf] Re: ProtoBuf 3 C# Options

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

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

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

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

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

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

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

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

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

Re: Performance comparison of Thrift, JSON and Protocol Buffers

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

Re: protocol buffers in .net

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

Re: Performance comparison of Thrift, JSON and Protocol Buffers

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

Re: protocol buffers in .net

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#

Re: Initial benchmarking committed to svn (r100)

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

Re: optimize_for option default

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

Re: Initial benchmarking committed to svn (r100)

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

Re: optimize_for option default

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

Re: optimize_for option default

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

Re: Streaming different types of messages

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

Re: Protocol Buffers Vs. XML Fast Infoset

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

Re: Performance comparison of Thrift, JSON and Protocol Buffers

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

Re: Immutability of generated data structures

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

[protobuf] Re: Report a bug

s "# 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, Fe

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

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

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

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?

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

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

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

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

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

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

[protobuf] Re: Json Program to Protobuf

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

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

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, Андрей

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

ber 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

  1   2   >