Re: [protobuf] Repeated double wire format: seen more variants, some cause problem in 3rd party decoders (ProtoBuf.jl at present time)

Tanmay was quick and he has already patched the ProtoBuf.jl. Many thanks to all for the proactive approach :-) Best regards, Marek On Tuesday, June 28, 2016 at 7:37:56 AM UTC+2, Tanmay K. Mohapatra wrote: > > Hi. > > Yes, ProtoBuf.jl decoder should accept both formats, which it does not as > of

Re: [protobuf] Repeated double wire format: seen more variants, some cause problem in 3rd party decoders (ProtoBuf.jl at present time)

Hi. Yes, ProtoBuf.jl decoder should accept both formats, which it does not as of now. I shall push a fix for that soon. The workaround suggested by Petteri will be useful in the meantime. Regards, Tanmay On Tuesday, June 28, 2016 at 11:00:51 AM UTC+5:30, jpa wrote: > > Hi, > > > > a) both

Re: [protobuf] Repeated double wire format: seen more variants, some cause problem in 3rd party decoders (ProtoBuf.jl at present time)

Hi, > > a) both variants are correct (so, ProtoBuf.jl shall be corrected) > > > > Is there any recommendation on how these repeated arrays shall be encoded? > > I tried to find the information at Google ProtoBuf website, but I have > > found only a very basic examples, not covering this in

Re: [protobuf] Repeated double wire format: seen more variants, some cause problem in 3rd party decoders (ProtoBuf.jl at present time)

On Monday, June 27, 2016 at 11:18:13 PM UTC+2, Feng Xiao wrote: > > > Repeated fields can be encoded in two forms: the regular form and the > packed form: > https://developers.google.com/protocol-buffers/docs/encoding#packed > > Both are valid and a parser is expected to be able to parse both. >

Re: [protobuf] Repeated double wire format: seen more variants, some cause problem in 3rd party decoders (ProtoBuf.jl at present time)

On Mon, Jun 27, 2016 at 12:40 PM, Marek Peca wrote: > Hello, > > last few weeks I am using ProtoBuf together with MQTT and sqlite to > control lab experiments and make logs of. Overall I am very satisfied, > using C/nanopb (without malloc), original C++ implementation