[protobuf] Protobuff project structure
Hello all I want to build a project using Java as server and Angular(ts) for client side I need to do something like a DTO project to define the structure of my enteties And seems like protobuff is a good way to do this , but I need to to have all protos in din different folders/subfolders/subsubfolders etcjust like packages in java then build all protos(from different subfolders but one root folder) in a single .jar file and add it top my server as a dependency then build as a ts interface (or something similar) and added in my cliend as a dependency My goal is to have the same structured data on client and server side without manual changeing ( just extend the profo file run a script and that`s it) can you guys give me some advise about how to do that ? thank you -- 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/7af9cd13-c014-41a1-b8ba-afe3e7bd338dn%40googlegroups.com.
Re: [protobuf] Immediately Interview QA Automation Tester. for my client in Rockville, MD.
Does this list not have a moderator who is able to block these unsolicited mails ?? It's really getting annoying... :-( Stefan -- ...ich hab' noch einen Koffer in Berlin... -- 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/514241c8-8861-27df-0d58-8aafa06080e8%40seefeld.name.
Re: [protobuf] Immediate Interview ll System Engineer with Electrical experience ll Columbus, IN, (100% interview with in 2 days)
Message to the list admin: would you *please* unsubscribe these spammers ? Thanks, On 2020-09-04 2:09 p.m., Jim alex wrote: Hello Associates, I have an Immediate need for a Systems Engineer with Electrical Experience. Kindly share suitable profiles at maz...@mirthconsulting.net <mailto:maz...@mirthconsulting.net> Job Title : Systems Engineer with Electrical Experience Location : Columbus, IN Duration : 6 months *All Visas Accepted * *Remote position* ** *My client is looking for consultants with 4 to 6 Years of experience. Consultants must have completed education in Electrical Engineering.* *RESPONSIBILITIES/ DUTIES:* • Interpret product design requirements to develop functional specifications and designs for hardware and system architecture • Conduct feasibility studies on requested features before confirming functional requirements • Select motor drivers, controllers, sensors, and other components that meet system requirements • Provide technical recommendations and guidance on component or system design • Create, analyze, and update technical documentation, test plans, and test reports • Maintain detailed schedules that support overall product schedules and properly communicate status to management *EDUCATION AND EXPERIENCE:* • Requires BS in Electrical Engineering, or related field of study *• 5+ years of systems experience required* *• CANbus experience required* *• Component selection such as sensors and motor drivers required* • Development experience with C/C++/C# preferred • Electric vehicle experience preferred • Battery energy system experience preferred. - Thanks & Regards. Mazhar Uddin | Technical recruiter http://www.mirthconsulting.net/assets/images/mirth2.png 6353 N Claremont Ave Chicago, IL. 60659 Direct: 312-414-6033- 312-428-5615 maz...@mirthconsulting.net <mailto:maz...@mirthconsulting.net>|*Error! Hyperlink reference not valid.* <http://www.mirthconsulting.net%7C/> https://www.linkedin.com/company/mirth-consulting-inc/ -- 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 <mailto:protobuf+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/protobuf/CAP63fLH1i76_jcRt%2BnHhSrv53SauJgTMOcKoLy4rHU-AkB2ayA%40mail.gmail.com <https://groups.google.com/d/msgid/protobuf/CAP63fLH1i76_jcRt%2BnHhSrv53SauJgTMOcKoLy4rHU-AkB2ayA%40mail.gmail.com?utm_medium=email&utm_source=footer>. Stefan -- ...ich hab' noch einen Koffer in Berlin... -- 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/db2125b6-e1b0-c04d-8a4a-37516d97f0c7%40seefeld.name.
Re: [protobuf] Framing protocol for variant message stream
On 2018-06-28 03:36 PM, John Lilley wrote: Reading about OneOf -- can I just union all of my messages into one "container" message? That's what I do, to map a class hierarchy to messages: I have an umbrella message corresponding to my base class, and a list of leaf node messages inside a OneOf representing all the concrete types I need to serialize. With that, serialization is a two-stage process: In the first stage I serialize into a string. In the second stage that string is then saved to a protobuf file, preceded with its size. Thus, when reading it back in, I first read that size, then the string (of the given size), which I then deserialize using the protobuf API into my actual message / class. That trick allows me to stream arbitrary numbers of objects / messages. Stefan -- ...ich hab' noch einen Koffer in Berlin... -- 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] Wrong namespace for InitDefaults??? and AddDescriptors ?
I believe you are describing the issue I reported earlier (https://groups.google.com/forum/#!topic/protobuf/Ja8IBAntTM0), and after not receiving any response filed an bug report for here: https://github.com/google/protobuf/issues/4737. Stefan -- ...ich hab' noch einen Koffer in Berlin... -- 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] modular API: "package" vs. "import"
Hello,
I'm trying to use protobuf in a project with multiple libraries, where
different libraries define message types that can ultimately be
combined. Thus I have different proto files, in different directories.
I understand I can use the "package" directive to let protoc generate
appropriate namespaces in the generated C++ code.
However, I'm surprised that the relative path location (as indicated
with the "import" directive) also influences the generated code.
Notably, I'm using `import "TSMarkers/Frame.proto"`, which causes a
function call "protobuf_TSMarkers_2fFrame_2eproto::InitDefaultsFrame();"
to be generated, though that function doesn't exist.
Is this behaviour documented somewhere ? I was thinking of the "import"
statement as something akin to C++ includes, where the path has no
bearing on how the (preprocessed) code is seen by the compiler, i.e. I'm
free to move C++ headers around, as long as I adjust the include search
paths. But with protoc, the (relative) location matters to the code.
Are there any guidelines on how to use protobuf (and protoc in
particular) in an environment with multiple ("distributed") proto files ?
(The CMake docs in
https://cmake.org/cmake/help/v3.9/module/FindProtobuf.html mention
"The |protobuf_generate_cpp| and |protobuf_generate_python| functions
and |add_executable()|
<https://cmake.org/cmake/help/v3.9/command/add_executable.html#command:add_executable>
or |add_library()|
<https://cmake.org/cmake/help/v3.9/command/add_library.html#command:add_library>
calls only work properly within the same directory.", which is rather
cryptic, but may hint things not working in non-local situations like
mine, though given that this is part of the CMake docs, I wouldn't
expect this to have any bearing on protobuf itself.)
Thanks,
Stefan
--
...ich hab' noch einen Koffer in Berlin...
--
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] read ahead from protobuf stream
Hi Josh, On 28.04.2018 13:06, Josh Humphries wrote: > You could use a length-delimited stream of google.protobuf.Any > messages. The Any message has a URL that encodes the fully-qualified > type of the message and then also the bytes of the corresponding > serialized proto. When I say length-delimited, I mean prefix each > message with a varint-encoded length (or fixed 32-bit length would > work, too). That is a common way to define a stream of protos, and > there is some library support -- at least in Java -- for the > varint-encoded delimited streams. Thanks. I actually found another solution that seems more elegant and convenient. After having defined my different message types M1, M2, ..., I define a wrapper type using `oneof`, and thus after reading the wrapper object I can simply query which type is wrapped (using `has_m1()` et al.), and then access the wrapped object directly. Cheers, Stefan -- ...ich hab' noch einen Koffer in Berlin... -- 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] read ahead from protobuf stream
Hello, I'm trying to use protocol buffers as a means to stream data, where an application would iteratively read messages from some input source. Messages have different types, so to be able to call `m.ParseFromIstream(input)` with an object `m` of appropriate type, I need to read ahead to identify the type of the next message so I can instantiate it. Do the IO APIs provide such a feature (I'm most interested into C++ and Python) ? I read about different ways to handle this (using `extend` to mimic polymorphism, mostly), I find that quite cumbersome and inefficient. So what's the best way to approach this ? Thanks, Stefan -- 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] OstreamOutputStream flush
I spent quite some time figuring out how to flush OstreamOutputStream because there is no Flush() method like in FileOutputStream. I finally realize that the only way to flush it is to delete it. It would be nice if this is mentioned somewhere in the document. Just a suggestion :) -- 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] protobufs 2.5.0
I am using eclipse and have compiled with protoc and included the protobuf java files in my project. I compiled by .proto file with protoc as well however I run into an error: com.google.protobuf.Descriptor cannot be resolved to a type And I am unsure why this is. I followed all the instructions in the README for compiling and made sure that the library version matched the protoc version. -- 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.
[protobuf] Re: building libprotobuf-lite for iPhone
Here's my version, using iOS SDK 5.1:
export ARCH=arm-apple-darwin10
export ARCH_PREFIX=$ARCH-
export PLATFORM=iPhoneOS
export SDKVER="5.1"
export
DEVROOT=/Applications/Xcode.app/Contents/Developer/Platforms/${PLATFORM}.platform/Developer
export SDKROOT="$DEVROOT/SDKs/${PLATFORM}$SDKVER.sdk"
export
PKG_CONFIG_PATH="$SDKROOT/usr/lib/pkgconfig:$DEVROOT/usr/lib/pkgconfig"
export AS="$DEVROOT/usr/bin/as"
export ASCPP="$DEVROOT/usr/bin/as"
export AR="$DEVROOT/usr/bin/ar"
export RANLIB="$DEVROOT/usr/bin/ranlib"
#export CPP="$DEVROOT/usr/bin/c++"
#export CXXCPP="$DEVROOT/usr/bin/c++"
export CC="$DEVROOT/usr/bin/gcc"
export CXX="$DEVROOT/usr/bin/g++"
export LD="$DEVROOT/usr/bin/ld"
export STRIP="$DEVROOT/usr/bin/strip"
export LIBRARY_PATH="$SDKROOT/usr/lib"
export CPPFLAGS=""
export CFLAGS="-arch armv7 -fmessage-length=0 -pipe -fpascal-strings
-miphoneos-version-min=4.0 -isysroot=$SDKROOT -I$SDKROOT/usr/include
-I$SDKROOT/usr/include/c++/4.2.1/"
export CXXFLAGS="$CFLAGS"
export LDFLAGS="-isysroot='$SDKROOT' -L$SDKROOT/usr/lib/system
-L$SDKROOT/usr/lib/"
./configure --host=${ARCH} --with-protoc=protoc --enable-static
--disable-shared
On Monday, November 1, 2010 4:39:27 PM UTC+1, Marcus Better wrote:
>
> Hi,
>
> I wonder if anyone has built libprotobuf-lite for the iOS, and if
> there are any special pitfalls?
>
> Cheers,
>
> Marcus
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/protobuf/-/QENKClHm36oJ.
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] Using protoc as Java DTO generation framework
Hi, i want to use protoc simply to generate Java DTO using the builder Pattern. I dont need the (de)serialization functionality, as these dtos are used in a JEE/GWT project to interchange data. Is there a way to reduce protoc´s capabilities that way ? Greetings Stefan -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To view this discussion on the web visit https://groups.google.com/d/msg/protobuf/-/9bCDs4aX8LEJ. 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: Arbitrary corruption of repeated fields
Madhav, I am not concerned with the integrity of the file itself. My only goal is to be able to read back (completely or partially) a message saved on disk in case file corruption occurs. A checksum would help to decide if the file got corrupted but would not help at all in recovering the data if indeed it got corrupted. On Jan 28, 12:19 am, Madhav Ancha wrote: > Stefan, > > Under what circumstances does persistence occur? If the message does not > break into smaller ones naturally and it makes sense to keep the message in > one piece, you can also use some checksum algorithm to verify your > persistence. > > -Madhav Ancha > > On Wed, Jan 27, 2010 at 11:57 PM, Stefan wrote: > > Kenton, Michael thanks for your quick answers (that was fast!). The > > suggestions are great and to the point (and if I remember correctly > > the approach was mentioned before). > > > So, a possible solution would be to break a big Bag into a couple of > > Bags with smaller number of items. Now, I would need a mechanism to > > write those smaller Bags delimited by some sort of a frame or marker. > > Next step would be to discard corrupted messages from the file (a > > corrupt message is one that does not parse) and seek to the next > > marker. If I want to lose no more than one message per corruption, I > > would need to write each Item separately but the overhead from the > > markers would be bigger. On the other hand, if the Bag has too many > > Items then I have the chance of losing too much data on a single > > corruption. Aside from the markers, I would get overhead from > > collating and separating the lists each time I need to use/save a big > > Bag. > > > I hope I got the idea correctly. I will give it a try (hopefully it > > will not be slow). > > > Again, thanks for your quick answers. > > > On Jan 27, 11:05 pm, Michael Poole wrote: > > > Stefan writes: > > > > What could I do reduce the risk of losing the entire list due to > > > > arbitrary corruption? What if corruption only occurs at the end of the > > > > file, would it be simpler to recover all the elements up to the > > > > corruption point? > > > > If you serialize the elements inside the Bag to the disk individually, > > > you could prefix them with a synchronizing marker and length. A marker > > > would typically be a fixed-length pattern that is unlikely to appear in > > > legitimate data -- starting with a zero byte is a good way given > > > Protocol Buffers data, it should contain some other (ideally uncommon) > > > bytes for robustness. > > > > By reading the marker, length, message, and checking the next marker, > > > your program can be reasonably sure that the detected message boundaries > > > are correct. Recovery then becomes a matter of looking for the next > > > synchronizing marker, and checking it the same way. > > > > There is obviously a tradeoff between how much data you can lose with a > > > corrupted message and the per-message overhead. If you were using the > > > particular example in your email, you might serialize a Bag that > > > contains several Items rather than serializing each Item individually. > > > > Michael Poole > > > -- > > 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. -- 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: Arbitrary corruption of repeated fields
Kenton, Michael thanks for your quick answers (that was fast!). The suggestions are great and to the point (and if I remember correctly the approach was mentioned before). So, a possible solution would be to break a big Bag into a couple of Bags with smaller number of items. Now, I would need a mechanism to write those smaller Bags delimited by some sort of a frame or marker. Next step would be to discard corrupted messages from the file (a corrupt message is one that does not parse) and seek to the next marker. If I want to lose no more than one message per corruption, I would need to write each Item separately but the overhead from the markers would be bigger. On the other hand, if the Bag has too many Items then I have the chance of losing too much data on a single corruption. Aside from the markers, I would get overhead from collating and separating the lists each time I need to use/save a big Bag. I hope I got the idea correctly. I will give it a try (hopefully it will not be slow). Again, thanks for your quick answers. On Jan 27, 11:05 pm, Michael Poole wrote: > Stefan writes: > > What could I do reduce the risk of losing the entire list due to > > arbitrary corruption? What if corruption only occurs at the end of the > > file, would it be simpler to recover all the elements up to the > > corruption point? > > If you serialize the elements inside the Bag to the disk individually, > you could prefix them with a synchronizing marker and length. A marker > would typically be a fixed-length pattern that is unlikely to appear in > legitimate data -- starting with a zero byte is a good way given > Protocol Buffers data, it should contain some other (ideally uncommon) > bytes for robustness. > > By reading the marker, length, message, and checking the next marker, > your program can be reasonably sure that the detected message boundaries > are correct. Recovery then becomes a matter of looking for the next > synchronizing marker, and checking it the same way. > > There is obviously a tradeoff between how much data you can lose with a > corrupted message and the per-message overhead. If you were using the > particular example in your email, you might serialize a Bag that > contains several Items rather than serializing each Item individually. > > Michael Poole -- 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] Arbitrary corruption of repeated fields
Hello everybody,
I have a small dilemma with regards to protocol buffers. I read the
documentation but I still do not see a clear answer (I only use the
Java version of protocol buffers). I hope I am not missing something
really obvious here ...
I have the following setup:
message Item {
optional string name = 1;
optional string description = 2;
}
message Bag{
repeated Item item= 1;
}
In the code, a Bag (with a significantly big number of items) gets
serialized to a file. Now, lets suppose the file gets corrupted in the
middle (arbitrary point). From my experiments, the entire content
would be lost because Bag cannot be deserialized anymore. To construct
the Bag, I use the parseFrom() method and I get exceptions. I do not
see anything in the documentation that would suggest mergeFrom() would
have a different result either.
I do not expect to be able to recover any individual corrupted items
but it would be nice to be able to recover the rest of the list.
What could I do reduce the risk of losing the entire list due to
arbitrary corruption? What if corruption only occurs at the end of the
file, would it be simpler to recover all the elements up to the
corruption point?
Thanks for your help!
--
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.
Re: java class name different from proto file name
Are you using Windows by any chance? On Aug 4, 11:54 am, Tai wrote: > I got a strange behaviour when compiling a protofile (e.g. > MyClass.proto). The generated java class is then called MyClassProto. > All other proto files works fine. As a workaround I have added the > following line to the proto file: > > option java_outer_classname = "MyClass"; > > Any idea what I am doing wrong? > > Thanks Tai --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
