Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1
The proto3 design discussion has lasted for more than half a year and all of them happened as an internal process. We have a lot of design docs, email exchanges and weekly design meetings, but they are not available for public consumption. Currently we are preparing public documentations for proto3 and it's targeted to be publicized late this quarter. On Wed Jan 21 2015 at 6:00:35 AM Sumit Kumar kumar.su...@hotmail.com wrote: Specially makes difficult for adoption in financial applications, the has_field was one of the key reasons to migrate over to protofuf. Financial applications need differentiation in-between 0 value set and not set. Eg: Limit order with 0 price is valid but with no price set is invalid. Likewise market order with no price set is valid and with any other price set is invalid (including the 0 value). And there are many other cases, but anyway if the decision is made then not much value discussing it. Regards, Sumit Kumar On 17 Jan 2015, at 10:52 am, V.B. vidalborro...@gmail.com wrote: I suppose what I'm really wondering is: a) How does it simplify the language implementations exactly? b) Why was that not the case for *non*-primitives, which still have presence logic? On Friday, January 16, 2015 at 6:39:56 PM UTC-5, Feng Xiao wrote: The reason for dropping field presence is more of the same with dropping default values. Basically we want to simplify protobuf and make it easier to implement efficiently in more languages. We are preparing the proto3 documentation and will share more information about the trade-offs we have made. On Fri Jan 16 2015 at 12:17:25 PM V.B. vidalb...@gmail.com wrote: Can I ask for more details about why presence logic was removed (e.g. hasFoo() ) for primitives? This has been a very useful feature for us. 1. Removal of field presence logic for primitive value fields, removal of required fields, and removal of default values. This makes proto3 significantly easier to implement with open struct representations, as in languages like Android Java, Objective C, or Go. -- 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+u...@googlegroups.com. To post to this group, send email to prot...@googlegroups.com. Visit this group at http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout. -- 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. -- 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. -- 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] Building for RTEMS ARM
Hello,
I am building Protocol Buffers from github for RTEMS
(http://www.rtems.org/) to run on a Xilinx Zynq (ARM CortexA9) and I am
making some progress but I have some questions.
I am using the current development head for RTEMS which is called 4.11 and
it is stable and almost about to be released. The gcc is:
$ arm-rtems4.11-gcc -v
Using built-in specs.
COLLECT_GCC=/opt/work/rtems/4.11/bin/arm-rtems4.11-gcc
COLLECT_LTO_WRAPPER=/opt/work/rtems/4.11/libexec/gcc/arm-rtems4.11/4.9.2/lto
-wrapper
Target: arm-rtems4.11
Configured with: ../gcc-4.9.2/configure --prefix=/opt/work/rtems/4.11 --
bindir=/opt/work/rtems/4.11/bin --exec_prefix=/opt/work/rtems/4.11 --
includedir=/opt/work/rtems/4.11/include --libdir=/opt/work/rtems/4.11/lib --
libexecdir=/opt/work/rtems/4.11/libexec --mandir=/opt/work/rtems/4.11/share/man
--infodir=/opt/work/rtems/4.11/share/info --datadir=/opt/work/rtems/4.11/share
--build=x86_64-freebsd10.0 --host=x86_64-freebsd10.0 --target=arm-rtems4.11
--disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib
--with-system-zlib --disable-nls --without-included-gettext
--disable-win32-registry
--enable-version-specific-runtime-libs --disable-lto
--enable-newlib-io-c99-formats
--enable-newlib-iconv --enable-newlib-iconv-encodings=big5,cp775,cp850,cp852
,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,
iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,
iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,
koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,
ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,
win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
--enable-threads --disable-plugin --enable-obsolete --enable-languages=c,c++
Thread model: rtems
gcc version 4.9.2 20141030 (RTEMS 4.11, RSB
e7cbf74fe2c94f0a233b8a7efcac3e75c239333c, Newlib
de616601501c4f82968683e80c112604a2d40222) (GCC)
The first are errors related to Atromics. We are adding -fpermissive to
make then warning. Here are a few of the many warnings we are seeing:
from ../../protobuf.git/src/google/protobuf/arenastring.h:
40,
from ../../protobuf.git/src/google/protobuf/descriptor.pb.h
:23,
from ../../protobuf.git/src/google/protobuf/compiler/ruby/
ruby_generator.cc:36:
../../protobuf.git/src/google/protobuf/stubs/once.h: In function 'void
google::protobuf::GoogleOnceInit(google::protobuf::ProtobufOnceType*, void
(*)())':
../../protobuf.git/src/google/protobuf/stubs/once.h:125:34: warning:
invalid conversion from 'google::protobuf::ProtobufOnceType* {aka int*}' to
'const
volatile Atomic32* {aka const volatile long int*}' [-fpermissive]
if (internal::Acquire_Load(once) != ONCE_STATE_DONE) {
^
In file included from ../../protobuf.git/src/google/protobuf/stubs/atomicops
.h:205:0,
from ../../protobuf.git/src/google/protobuf/stubs/
atomic_sequence_num.h:33,
from ../../protobuf.git/src/google/protobuf/arena.h:38,
from ../../protobuf.git/src/google/protobuf/descriptor.pb.h
:22,
from ../../protobuf.git/src/google/protobuf/compiler/ruby/
ruby_generator.cc:36:
../../protobuf.git/src/google/protobuf/stubs/atomicops_internals_arm_gcc.h:
136:17: note: initializing argument 1 of 'google::protobuf::internal::Atomic32
google::protobuf::internal::Acquire_Load(const volatile Atomic32*)'
The other issue is RTEMS is not self hosting and so always cross-compiled.
Is there a way to disable running tests ? It makes no sense to run the
tests when the build and host are not the same.
Thanks
Chris
--
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.
Re: [protobuf] Can protobuf work with C++ templates?
This is not really a protobuf question, moreso a C++ question. But anyways,
the typical way to do this is:
template typename T struct MatrixTraits { };
template struct MatrixTraitsdouble { typedef DoubleMatrix type; };
template struct MatrixTraitsfloat{ typedef FloatMatrix type; };
template typename DType class Matrix {
typename MatrixTraitsDType::type mat_data_;
};
On Mon, Jan 19, 2015 at 5:41 PM, Ji Wan wa...@live.com wrote:
Suppose I have two message types `DoubleMatrix` and `FloatMatrix`, and a
template class `Matrix`:
message DoubleMatrix {
required uint32 rows = 1;
required uint32 cols = 2;
repeated double data = 3 [packed=true];
}
message FloatMatrix {
required uint32 rows = 1;
required uint32 cols = 2;
repeated float data = 3 [packed=true];
}
templatetypename DType
class Matrix {
MSTType mat_data_;
};
Is it possible to make `MSTType` as `FloatMatrix` if `DType` is `float`, as
`DoubleMatrix` if `DType` is `double`?
--
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.
--
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] Issue 686 in protobuf: Protoc does not provide a dependency manifest output file for build tools like make
Status: New Owner: liuj...@google.com Labels: Type-Defect Priority-Medium New issue 686 by richardg...@gmail.com: Protoc does not provide a dependency manifest output file for build tools like make https://code.google.com/p/protobuf/issues/detail?id=686 Protobuf files can have import statements and include directories, so the full dependency tree is not known by the build system before executing protoc. This makes it hard for the build system to know when to schedule any given protoc command. Make other build systems can use a dependency file to trigger a rebuild when a dependency changes. GCC and other compilers expose this with the -MF flag, which outputs a file in the format output_filename: input_file \ input_file2 \ input_file3 ... Protobuf knows the transitive set of input files, but doesn't expose this information in this format. Patch to follow. -- 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/d/optout.
Re: [protobuf] Can protobuf work with C++ templates?
Got a new skill :P
Thanks very much!
--- Original Message ---
From: Stephen Tu tu.steph...@gmail.com
Sent: January 22, 2015 1:28 AM
To: Ji Wan wa...@live.com
Cc: protobuf@googlegroups.com
Subject: Re: [protobuf] Can protobuf work with C++ templates?
This is not really a protobuf question, moreso a C++ question. But anyways,
the typical way to do this is:
template typename T struct MatrixTraits { };
template struct MatrixTraitsdouble { typedef DoubleMatrix type; };
template struct MatrixTraitsfloat{ typedef FloatMatrix type; };
template typename DType class Matrix {
typename MatrixTraitsDType::type mat_data_;
};
On Mon, Jan 19, 2015 at 5:41 PM, Ji Wan wa...@live.com wrote:
Suppose I have two message types `DoubleMatrix` and `FloatMatrix`, and a
template class `Matrix`:
message DoubleMatrix {
required uint32 rows = 1;
required uint32 cols = 2;
repeated double data = 3 [packed=true];
}
message FloatMatrix {
required uint32 rows = 1;
required uint32 cols = 2;
repeated float data = 3 [packed=true];
}
templatetypename DType
class Matrix {
MSTType mat_data_;
};
Is it possible to make `MSTType` as `FloatMatrix` if `DType` is `float`, as
`DoubleMatrix` if `DType` is `double`?
--
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.
--
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.
Re: [protobuf] Re: Protobuf Buffers v3.0.0-alpha-1
Specially makes difficult for adoption in financial applications, the has_field was one of the key reasons to migrate over to protofuf. Financial applications need differentiation in-between 0 value set and not set. Eg: Limit order with 0 price is valid but with no price set is invalid. Likewise market order with no price set is valid and with any other price set is invalid (including the 0 value). And there are many other cases, but anyway if the decision is made then not much value discussing it. Regards, Sumit Kumar On 17 Jan 2015, at 10:52 am, V.B. vidalborro...@gmail.com wrote: I suppose what I'm really wondering is: a) How does it simplify the language implementations exactly? b) Why was that not the case for non-primitives, which still have presence logic? On Friday, January 16, 2015 at 6:39:56 PM UTC-5, Feng Xiao wrote: The reason for dropping field presence is more of the same with dropping default values. Basically we want to simplify protobuf and make it easier to implement efficiently in more languages. We are preparing the proto3 documentation and will share more information about the trade-offs we have made. On Fri Jan 16 2015 at 12:17:25 PM V.B. vidalb...@gmail.com wrote: Can I ask for more details about why presence logic was removed (e.g. hasFoo() ) for primitives? This has been a very useful feature for us. 1. Removal of field presence logic for primitive value fields, removal of required fields, and removal of default values. This makes proto3 significantly easier to implement with open struct representations, as in languages like Android Java, Objective C, or Go. -- 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+u...@googlegroups.com. To post to this group, send email to prot...@googlegroups.com. Visit this group at http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout. -- 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. -- 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.
