can not build check code in AIX
hi, i am work in aix 5.3, xlc++ v10.1 # make check Making check in . make[1]: Entering directory `/home/source/cpp/protobuf-2.2.0-build-32' make check-local make[2]: Entering directory `/home/source/cpp/protobuf-2.2.0-build-32' Making lib/libgtest.a lib/libgtest_main.a in gtest make[3]: Entering directory `/home/source/cpp/protobuf-2.2.0-build-32/ gtest' make[3]: `lib/libgtest.la' is up to date. make[3]: `lib/libgtest_main.la' is up to date. make[3]: Leaving directory `/home/source/cpp/protobuf-2.2.0-build-32/ gtest' make[2]: Leaving directory `/home/source/cpp/protobuf-2.2.0-build-32' make[1]: Leaving directory `/home/source/cpp/protobuf-2.2.0-build-32' Making check in src make[1]: Entering directory `/home/source/cpp/protobuf-2.2.0-build-32/ src' make check-am make[2]: Entering directory `/home/source/cpp/protobuf-2.2.0-build-32/ src' make protobuf-test protobuf-lazy-descriptor-test protobuf-lite-test zcgzip zcgunzip make[3]: Entering directory `/home/source/cpp/protobuf-2.2.0-build-32/ src' source='google/protobuf/repeated_field_unittest.cc' object='protobuf_test-repeated_field_unittest.o' libtool=no \ DEPDIR=.deps depmode=aix /opt/freeware/bin/bash ../../ protobuf-2.2.0/depcomp \ xlc++ -DHAVE_CONFIG_H -I. -I../../protobuf-2.2.0/src -I.. - I../../protobuf-2.2.0/gtest/include -I../gtest/include - D_THREAD_SAFE -DNDEBUG -c -o protobuf_test-repeated_field_unittest.o `test -f 'google/protobuf/repeated_field_unittest.cc' || echo '../../ protobuf-2.2.0/src/'`google/protobuf/repeated_field_unittest.cc ../../protobuf-2.2.0/src/google/protobuf/repeated_field.h, line 893.19: 1540-0704 (S) The definitions of google::protobuf::internal::RepeatedPtrIteratorconst std::basic_stringchar,std::char_traitschar,std::allocatorchar goog... and google::protobuf::internal::RepeatedPtrIteratorstd::basic_stringchar,std::char_traitschar,std::allocatorchar google::pr... have thesame linkage signature __pl__Q3_6google8protobuf8internalFQ4_6google8protobuf8internal19RepeatedPtrIteratorXTQ2_3std12basic_stringXTcTQ2_3std11char_trai make[3]: *** [protobuf_test-repeated_field_unittest.o] Error 1 make[3]: Leaving directory `/home/source/cpp/protobuf-2.2.0-build-32/ src' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/source/cpp/protobuf-2.2.0-build-32/ src' make[1]: *** [check] Error 2 make[1]: Leaving directory `/home/source/cpp/protobuf-2.2.0-build-32/ src' make: *** [check-recursive] Error 1 # best regards alex --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
extension_set.h can not be resolved by xlc + + properly
hi when i #include google/protobuf/extension_set.h the xlc++ always show an error message: /home/soft/include/google/protobuf/extension_set.h, line 378.10: 1540-0063 (S) The text ( is unexpected. line 377 to 379 int GetSize() const; void Free(); int SpaceUsedExcludingSelf() const; xlc++ v10.1 , aix 5.3 can you give me some suggestions? thanks alex --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Java generated code: faster equals() and hashCode()
Hi, On Fri, 2009-09-25 at 16:41 +0300, Daniel Augustin Pavel wrote: I've worked a bit on improving the perfomance of equals() and hashCode() for the generated message clases. [snipped] My implementation of equals() compares the two messages field-by-field. In tests, for equal objects it is about an order of magnitude faster than the default. The hashCode() value is cached (the objects are supposed to be immutable anyway), speeding up equals() in the not-equal case by another order of magnitude. I think it would be safer to do this: + printer-Print( +if (otherObject == this) return true;\n +if (!(otherObject instanceof $classname$)) return false;\n +if (hashCode() != otherObject.hashCode()) return false;\n +$classname$ other = ($classname$) otherObject;\n, +classname, descriptor_-name()); (I reversed the hashCode test and the instanceof test) This way if I happen to pbObject.equals(null) it won't throw a NullPointerException, but just say they're not equals (which they are, right?) For LITE messages, which don't use the AbstractMessage implementations, the hashCode is computed by going through all the fields. The only downside is that the size of the generated classes increases (additional bytecode), proportional to the number of fields in the message. Would love to hear feedback on the patch -- anyone finding it useful / appropiate? This is a good addition. I really like it. It'd be really great if it would be merged in the next revision. -- Brice Figureau My Blog: http://www.masterzen.fr/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Process Emails From Home. Make $200+ Daily
You will get paid $20.00 for every email you process online. Our program requires only basic computer skills and can be done wherever you have access to the Internet. http://processemailonline.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Fwd: Java generated code: faster equals() and hashCode()
Aaand forgot to reply all. Apologies. Cheers, -pwr -- Forwarded message -- From: Daniel Augustin Pavel daniel.pa...@gmail.com Date: Fri, Sep 25, 2009 at 19:04 Subject: Re: Java generated code: faster equals() and hashCode() To: Brice Figureau brice...@daysofwonder.com On Fri, Sep 25, 2009 at 18:12, Brice Figureau brice...@daysofwonder.com wrote: I think it would be safer to do this: + printer-Print( + if (otherObject == this) return true;\n + if (!(otherObject instanceof $classname$)) return false;\n + if (hashCode() != otherObject.hashCode()) return false;\n + $classname$ other = ($classname$) otherObject;\n, + classname, descriptor_-name()); (I reversed the hashCode test and the instanceof test) This way if I happen to pbObject.equals(null) it won't throw a NullPointerException, but just say they're not equals (which they are, right?) Quite right. I was under the impression that most equals() implementation happily throw NPE when comparinga against a null, so did not think much of it. Checked now more closely a few classes in the JDK, and I was obviously wrong. I've attached the fixed patch. Cheers, -pwr -- Time is an illusion. Lunchtime doubly so. -- Douglas Adams --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- improved_equals_2.diff Description: Binary data
Re: extension_set.h can not be resolved by xlc + + properly
Maybe your system headers #define Free as a macro? Try adding #undef Free before that line. On Fri, Sep 25, 2009 at 7:25 AM, alex as.von.ch...@gmail.com wrote: hi when i #include google/protobuf/extension_set.h the xlc++ always show an error message: /home/soft/include/google/protobuf/extension_set.h, line 378.10: 1540-0063 (S) The text ( is unexpected. line 377 to 379 int GetSize() const; void Free(); int SpaceUsedExcludingSelf() const; xlc++ v10.1 , aix 5.3 can you give me some suggestions? thanks alex --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: extension_set.h can not be resolved by xlc + + properly
Maybe 'Free' is a macro defined in that compiler environment ? (would be bad, but these things happen). What happens if you do an #undef Free in front of that On Fri, Sep 25, 2009 at 07:25, alex as.von.ch...@gmail.com wrote: hi when i #include google/protobuf/extension_set.h the xlc++ always show an error message: /home/soft/include/google/protobuf/extension_set.h, line 378.10: 1540-0063 (S) The text ( is unexpected. int GetSize() const; #undef Free void Free(); int SpaceUsedExcludingSelf() const; xlc++ v10.1 , aix 5.3 can you give me some suggestions? thanks alex --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: extension_set.h can not be resolved by xlc + + properly
Jinx. :) On Fri, Sep 25, 2009 at 10:04 AM, Henner Zeller h.zel...@acm.org wrote: Maybe 'Free' is a macro defined in that compiler environment ? (would be bad, but these things happen). What happens if you do an #undef Free in front of that On Fri, Sep 25, 2009 at 07:25, alex as.von.ch...@gmail.com wrote: hi when i #include google/protobuf/extension_set.h the xlc++ always show an error message: /home/soft/include/google/protobuf/extension_set.h, line 378.10: 1540-0063 (S) The text ( is unexpected. int GetSize() const; #undef Free void Free(); int SpaceUsedExcludingSelf() const; xlc++ v10.1 , aix 5.3 can you give me some suggestions? thanks alex --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Java generated code: faster equals() and hashCode()
I do agree that this should not be applied for LITE_RUNTIME because of the lite runtime goal. However an extra option could be added where these equals() and hashCode() are implemented. LITE_RUNTIME_EXTRA maybe. (any name is fine) Those 2 methods are definitely needed in most cases. Cheers On Sat, Sep 26, 2009 at 1:02 AM, Kenton Varda ken...@google.com wrote: On Fri, Sep 25, 2009 at 6:41 AM, Daniel Augustin Pavel daniel.pa...@gmail.com wrote: Hello, I've worked a bit on improving the perfomance of equals() and hashCode() for the generated message clases. Cool! Unfortunately, increasing the generated code size really is a big problem. Protobuf generated code is *huge*, and we're always looking for ways to reduce it. We made a conscious decision not to implement equals() and hashCode() in generated code because, in our experience, these methods are rarely actually desired outside of tests, so the benefit of reducing the generated code size outweighs the cost of these methods being slow. Can you tell us a bit about your use case? Again, in my experience, people who are comparing message objects by content outside of tests are almost always doing something they don't need to be (usually they actually want to compare by identity instead). But, I'm willing to be proven wrong. BTW, another way you could possibly speed up equals() and hashCode() is to serialize the objects and compare raw bytes. This can be done pretty easily in a wrapper class, without modifying the protobuf implementation. You could also implement your hash-caching trick in a wrapper class, which alone could probably make a huge difference for List.contains(). Or we could perhaps implement the hash caching in the official implementation, since it wouldn't require new generated code. The above does not apply to LITE messages from what I can tell, they just use the standard Object implementation of these methods (which I find quite inappropiate for the kind of data protobuf objects are supposed to represent). The goal of lite messages is to shed features in order to reduce code size. equals() and hashCode() were two of the casualties. Since lite messages don't support reflection, our options were either to generate more code (bad -- lite users are exactly the users who don't want more code) or not implement them. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: warnings compiling generated code on Snow Leopard
So is there a decision for this issue? Will it be a flag for protoc or a patch (I think I saw somewhere a post mentioning that the patch was not going to be used because of other issues)? And any possible ETA for the solution? On Aug 31, 5:33 pm, Kenton Varda ken...@google.com wrote: I'm OK with a patch that just adds the call to Message(). I'm not OK with a patch that explicitly initializes every single field, which is what Michael is talking about, since it conflicts with an optimization we did to reduce code size. I'd also rather not add an option for this because it would be tedious to maintain and test and we have too many options already. On Mon, Aug 31, 2009 at 5:17 PM, Michael Poole mdpo...@troilus.org wrote: Joshua Haberman writes: The protobuf library compiled and installed fine, but the generated classes threw warnings (and since I was compiling with -Werror, failed to compile). The warning was: benchmarks/google_messages.pb.cc: In copy constructor ‘benchmarks::SpeedMessage2::SpeedMessage2(const benchmarks::SpeedMessage2)’: benchmarks/google_messages.pb.cc:4179: warning: base class ‘class google::protobuf::Message’ should be explicitly initialized in the copy constructor I thought this was an odd warning, since the constructors don't explicitly initialize their base classes, and do not throw warnings. I also thought it was odd since other versions of gcc don't throw this warning AFAIK. This warning is triggered by using g++'s -Weffc++ warning flag. I raised this before[1], with a patch that was backed out because it led to constructor code being duplicated. Making both sides happy probably involves adding a command-line flag to protoc that toggles how it generates code: by default, omitting those constructor calls, but allowing the user to ask for those constructors to be called. Kenton, would that be a reasonable approach? If so, I should have time to update my patch to do that and resubmit. [1]http://code.google.com/p/protobuf/issues/detail?id=86 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 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 -~--~~~~--~~--~--~---
Re: warnings compiling generated code on Snow Leopard
On Fri, Sep 25, 2009 at 12:25, mo mohammad.kolahdou...@gmail.com wrote: So is there a decision for this issue? Will it be a flag for protoc or a patch (I think I saw somewhere a post mentioning that the patch was not going to be used because of other issues)? And any possible ETA for the solution? You could be the one sending the patch, then you can influence the time ;) Whenever I find something wrong with an open source project I submit a patch to fix it - waiting that 'someone else' will do it is usually too late. -h --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Options prefixing length and message type information
protobuf is very cool. There are two options which I think would be very helpful: 1) An option to prefix a length field to each message. This would make it possible to serialize/deserialize a stream of bytes (e.g., a TCP socket). 2) An option for prefixing a type field to each message -- this makes it possible to tell what message type is coming over a stream of bytes. This is useful in some cases where you expect a message but don't know what kind. For now I can manually prefix these values, but I these options are useful enough that adding options to enable the protoc compiler to automatically do this work would be worthwhile. Thanks for a great tool! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Options prefixing length and message type information
On Fri, Sep 25, 2009 at 1:28 PM, dound doun...@gmail.com wrote: 1) An option to prefix a length field to each message. This would make it possible to serialize/deserialize a stream of bytes (e.g., a TCP socket). This is sort of out of scope of what protobuf does. It should be handled by whatever RPC framework you use, or handled by hand in whatever protocol you use to send things over the network, or save things to files, or whatever you're doing with your protobuf objects. 2) An option for prefixing a type field to each message -- this makes it possible to tell what message type is coming over a stream of bytes. This is useful in some cases where you expect a message but don't know what kind. Kenton, please correct me if I'm wrong, but if the receiving end had the same compiled code as the sending end you can ask the Message object for it's Descriptor, which contains information about the message including it's name. If that is not true, you can create a wrapper message that contains the name of the object. Thanks for a great tool! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: protobuf-2.2.0 java compilation errors
regionStart() is there since JDK 1.5
http://java.sun.com/j2se/1.5.0/docs/api/java/util/regex/Matcher.html#regionStart()
What is your java version ?
On Fri, Sep 25, 2009 at 15:54, matt matt.hender...@lucidsw.com.au wrote:
I have compiled C++ protobuf successfully but am having enormous
difficulty compiling the java code. I initially tried manually and
after two days relinquished and installed Maven as recommended in the
README. Building under Maven produced the same errors.
ie:
1. ERROR in /home/matth/pkgs/protobuf-2.2.0/java/src/main/java/com/
google/protobuf/TextFormat.java (at line 463)
while (pos matcher.regionStart()) {
^^^
The method regionStart() is undefined for the type Matcher
--
2. ERROR in /home/matth/pkgs/protobuf-2.2.0/java/src/main/java/com/
google/protobuf/TextFormat.java (at line 474)
if (matcher.regionStart() == matcher.regionEnd()) {
^^^
The method regionStart() is undefined for the type Matcher
--
3. ERROR in /home/matth/pkgs/protobuf-2.2.0/java/src/main/java/com/
google/protobuf/TextFormat.java (at line 474)
if (matcher.regionStart() == matcher.regionEnd()) {
^
The method regionEnd() is undefined for the type Matcher
And it goes on.
Can anyone please suggest how I might overcome these issues.
Thanking you in advance.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
protobuf-2.2.0 java compilation errors
I have compiled C++ protobuf successfully but am having enormous
difficulty compiling the java code. I initially tried manually and
after two days relinquished and installed Maven as recommended in the
README. Building under Maven produced the same errors.
ie:
1. ERROR in /home/matth/pkgs/protobuf-2.2.0/java/src/main/java/com/
google/protobuf/TextFormat.java (at line 463)
while (pos matcher.regionStart()) {
^^^
The method regionStart() is undefined for the type Matcher
--
2. ERROR in /home/matth/pkgs/protobuf-2.2.0/java/src/main/java/com/
google/protobuf/TextFormat.java (at line 474)
if (matcher.regionStart() == matcher.regionEnd()) {
^^^
The method regionStart() is undefined for the type Matcher
--
3. ERROR in /home/matth/pkgs/protobuf-2.2.0/java/src/main/java/com/
google/protobuf/TextFormat.java (at line 474)
if (matcher.regionStart() == matcher.regionEnd()) {
^
The method regionEnd() is undefined for the type Matcher
And it goes on.
Can anyone please suggest how I might overcome these issues.
Thanking you in advance.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: protobuf-2.2.0 java compilation errors
On Fri, Sep 25, 2009 at 15:59, Matt Henderson
matt.hender...@lucidsw.com.au wrote:
Thank you for your prompt response:
Eclipse Java Compiler 0.793_R33x, 3.3.2
I was using the -5 switch for java5 / 1.5 computability
mmh, some time ago that I used Eclipse. Maybe the bytecode
compatibility is set for 1.5 but it still uses a 1.4 jre.jar somewhere
? IIRC, there is a tab somewhere to figure out what 'system jars' it
includes in the project.
Henner Zeller wrote:
regionStart() is there since JDK 1.5
http://java.sun.com/j2se/1.5.0/docs/api/java/util/regex/Matcher.html#regionStart()
What is your java version ?
On Fri, Sep 25, 2009 at 15:54, matt matt.hender...@lucidsw.com.au wrote:
I have compiled C++ protobuf successfully but am having enormous
difficulty compiling the java code. I initially tried manually and
after two days relinquished and installed Maven as recommended in the
README. Building under Maven produced the same errors.
ie:
1. ERROR in /home/matth/pkgs/protobuf-2.2.0/java/src/main/java/com/
google/protobuf/TextFormat.java (at line 463)
while (pos matcher.regionStart()) {
^^^
The method regionStart() is undefined for the type Matcher
--
2. ERROR in /home/matth/pkgs/protobuf-2.2.0/java/src/main/java/com/
google/protobuf/TextFormat.java (at line 474)
if (matcher.regionStart() == matcher.regionEnd()) {
^^^
The method regionStart() is undefined for the type Matcher
--
3. ERROR in /home/matth/pkgs/protobuf-2.2.0/java/src/main/java/com/
google/protobuf/TextFormat.java (at line 474)
if (matcher.regionStart() == matcher.regionEnd()) {
^
The method regionEnd() is undefined for the type Matcher
And it goes on.
Can anyone please suggest how I might overcome these issues.
Thanking you in advance.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
