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, <[email protected]> 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> > > [email protected] Aug 06 10:53AM > > Status: New > Owner: ---- > Labels: Type-Defect Priority-Medium > > New issue 541 by [email protected]: 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." <[email protected]> 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 <[email protected]> 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." <[email protected]> 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." <[email protected]> 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 <[email protected]> Aug 05 07:59PM -0700 > > > > Question about size/speed of protobufs with different > formats<http://groups.google.com/group/protobuf/t/6e0bb65530d38024> > > George Wong <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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> > > [email protected] Aug 05 05:00PM > > Updates: > Status: Fixed > > Comment #1 on issue 540 by [email protected]: 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/groups/opt_out.
