Hi, I'm looking for a toll which will generate MySQL/SQLite schemas from .proto files.
http://stackoverflow.com/questions/18082871/im-looking-for-a-tool-which-processes-proto-files-into-mysql-sqlite-schemas Thanks, Chris. On 6 August 2013 13:42, <protobuf@googlegroups.com> wrote: > Today's Topic Summary > > Group: http://groups.google.com/group/protobuf/topics > > - Issue 541 in protobuf: Double decode in > google.protobuf.text_format._CUnescape<#14053a61a6c9c0b2_group_thread_0>[1 > Update] > - ByteString using N bytes from an > InputStream?<#14053a61a6c9c0b2_group_thread_1>[4 Updates] > - protobuf mingw error <#14053a61a6c9c0b2_group_thread_2> [1 Update] > - Question about size/speed of protobufs with different > formats<#14053a61a6c9c0b2_group_thread_3>[2 Updates] > - Using Options <#14053a61a6c9c0b2_group_thread_4> [1 Update] > - Protocol Buffers Specification and the syntax > keyword.<#14053a61a6c9c0b2_group_thread_5>[1 Update] > - Issue 540 in protobuf: Add protoc-gen-haxe to ThirdPartyAddOns wiki > page, please <#14053a61a6c9c0b2_group_thread_6> [1 Update] > > Issue 541 in protobuf: Double decode in > google.protobuf.text_format._CUnescape<http://groups.google.com/group/protobuf/t/86c0c99e91cd1958> > > proto...@googlecode.com Aug 06 10:53AM > > Status: New > Owner: ---- > Labels: Type-Defect Priority-Medium > > New issue 541 by matt.k...@undue.org: Double decode in > google.protobuf.text_format._CUnescape > http://code.google.com/p/protobuf/issues/detail?id=541 > > What steps will reproduce the problem? > > >>> print google.protobuf.text_format._CUnescape('\\x5c') > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File > "/usr/lib/python2.7/dist-packages/google/protobuf/text_format.py", > line 691, in _CUnescape > return result.decode('string_escape') > ValueError: Trailing \ in string > > What is the expected output? What do you see instead? > > The expected output is a single backslash. _CUnescape works if the > input > is instead given in octal: > > >>> print google.protobuf.text_format._CUnescape('\\134') > \ > > When the input is given in hex the escaped backslash is unescaped > _twice_, > once in the re.sub() and once in the str.decode(). > > I'm not using the trunk HEAD but I can see that the issue is still > present. > > -- > You received this message because this project is configured to send > all > issue notifications to this address. > You may adjust your notification preferences at: > https://code.google.com/hosting/settings > > > > ByteString using N bytes from an > InputStream?<http://groups.google.com/group/protobuf/t/1903436bc567615e> > > "V.B." <vidalborro...@gmail.com> Aug 05 03:23PM -0700 > > Greetings all, > We are using version 2.5. What is the most efficient way (*i.e.* > single > copy operation, no extra byte arrays) to construct a ByteString from a > specific number of bytes in an InputStream? The various versions of > ByteString.readFrom() drain the stream completely, which is not what > we > need; any data past *N* bytes should remain in the stream. The > ByteString.readChunk() method looks like it will work if we simply > give it * > N* as the chunkSize parameter. Unfortunately, ByteString.readChunk() > is > declared private, so that method is not currently an option. Is there > another option that I just haven't found in the source code yet? > > (Thanks for taking the time to read this question.) > > > > > Feng Xiao <xiaof...@google.com> Aug 05 04:32PM -0700 > > > ByteString.readChunk() method looks like it will work if we simply > give > > it *N* as the chunkSize parameter. Unfortunately, > ByteString.readChunk()is declared private, so that method is not currently > an option. Is there > > another option that I just haven't found in the source code yet? > > How about create an wrapper InputStream that only reads N bytes from > the > original InputStream and provide the wrapper to BytesString.readFrom()? > > > > > > > "V.B." <vidalborro...@gmail.com> Aug 05 09:28PM -0700 > > Hi Feng Xiao! Thanks for the response. > That's actually our backup plan. We were hoping to avoid it, though, > since the wrappers would each contain an extra copy of the data > internally. > Our ideal case is for the data to get copied in a single step directly > from > an InputStream to a ByteString with no intermediate copies along the > way. > Question: You would know best... Would the safety of ByteStrings be > preserved if the readChunk() method were to be made public? If so, > I'll > open a feature request on the issue tracker. > > On Monday, August 5, 2013 7:32:49 PM UTC-4, Feng Xiao wrote: > > > > > "V.B." <vidalborro...@gmail.com> Aug 05 09:31PM -0700 > > ... Actually, I just now took a closer look at the readChunk() method. > Even > that method makes an internal copy, so it looks like readChunk() isn't > what > we are looking for after all. Hmmm. > > On Tuesday, August 6, 2013 12:28:56 AM UTC-4, V.B. wrote: > > > > protobuf mingw > error<http://groups.google.com/group/protobuf/t/854cfcbde4025497> > > anonymous <samueljlehm...@gmail.com> Aug 05 07:59PM -0700 > > > > Question about size/speed of protobufs with different > formats<http://groups.google.com/group/protobuf/t/6e0bb65530d38024> > > George Wong <georgewon...@gmail.com> Aug 05 10:32AM -0700 > > Hello, > > I was wondering which of the following ways to define a .proto would > be > faster / more space efficient -- or if there'd be no difference at > all... > > Option 1: > message Packet { > > ... > repeated Process process = 6; > ... > message Process { > optional uint32 pid = 1; > ... > optional string execname = 14; > } > } > > or Option 2: > message Packet { > > ... > optional uint32 pid1 = 6; > ... > optional string execname1 = 20; > optional uint32 pid2 = 21; > ... > optional string execname2 = 35; > } > > > I'm essentially wondering what effect "loop unwinding" has in a > protobuf (and yes, I know how many of the Process protos I have). Because > the ID is used, I'm wondering if the extra byte (when you go from 15 to > 255) is that much of an issue. Also I'm not sure how actually reading into > the "repeated" works, so I'm wondering about speed (in > creation/setting/encoding/decoding/reading). > > > Thanks! > > > > > Ilia Mirkin <imir...@alum.mit.edu> Aug 05 01:45PM -0400 > > Well, for regular values, it goes <tag> <value>, for a subproto it > goes <tag> <length> <submessage> (which in turn has <tag> <value> > pairs in it). So it depends on the number of fields inside of the > message, and how many bytes it is total. But assuming non-edge-case > conditions, you're probably better off using a submessage and smaller > tag ids (i.e. < 16) than unwinding the repeated (or, indeed, even if > it were a single message). Hm, this also creates an interesting aside, > which is that perhaps it is more efficient to only ever use tag ids < > 16 and once you go over that, stick the rest of the fields into a > submessage. It'd make for very confusing code though. > > In terms of speed, you end up creating more objects/have recursion > when dealing with submessages, so "loop unrolling" could be effective > there. (By very very small amounts, usually I/O is the limiting > factor.) As always, with such things, benchmark it :) > > -ilia > > > > > Using Options<http://groups.google.com/group/protobuf/t/17cae45c1890c14d> > > Muthu <prmuthu...@gmail.com> Aug 05 12:50AM -0700 > > Hi, > > I'm using managed C++ project(IDE:visual studio 2010) as an > intermediate > project to consume the .h and .cpp files given by the protoc. when I > try to > use GetExtension method [ > MyMessage::descriptor()->options().GetExtension(my_option)] > in the managed C++ project to get the option value and compile, It is > getting into some infinite loop building. Some ambiguity is causing > this > issue. When I right click the GetExtension to go the declaration it is > refering to C:\Program Files\Microsoft > SDKs\Windows\v7.0A\Include\UriMon.h. > How to resolve this ambiguity. Please help me solve this issue. > > > > Protocol Buffers Specification and the syntax > keyword.<http://groups.google.com/group/protobuf/t/9daf4196ee7d0370> > > Feng Xiao <xiaof...@google.com> Aug 05 10:08AM -0700 > > > other cases. > > > Is there a more complete or up to date specification of the .proto > format > > I might have missed? > > The "syntax" keyword is only used in Google internally. It's not > supported > in opensource protobuf. > > > > > > Issue 540 in protobuf: Add protoc-gen-haxe to ThirdPartyAddOns wiki > page, please <http://groups.google.com/group/protobuf/t/926c8c8adc4bd63e> > > proto...@googlecode.com Aug 05 05:00PM > > Updates: > Status: Fixed > > Comment #1 on issue 540 by xiaof...@google.com: Add protoc-gen-haxe to > ThirdPartyAddOns wiki page, please > http://code.google.com/p/protobuf/issues/detail?id=540 > > Done. Thanks. > > -- > You received this message because this project is configured to send > all > issue notifications to this address. > You may adjust your notification preferences at: > https://code.google.com/hosting/settings > > > > -- > 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/groups/opt_out. > > > -- 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/groups/opt_out.
