Re: [protobuf] could anyone give me the source code of protobuffer 2.0.3

[Ilia Mirkin]

Not easy to find anymore it seems... looks like all the old releases
have been lost in the move to github. That's unfortunate.

http://ftp.slackware.com/pub/gsb/gsb64-2.28_slackware64-13.1/source/c/protobuf/protobuf-2.0.3.tar.bz2
http://www.java2s.com/Code/Jar/p/Downloadprotobufjava203jar.htm

No clue how authoritative these are. Use with care.


On Wed, Aug 9, 2017 at 11:54 PM,   wrote:
> My project is using this old version, but the source code of protobuffer
> 2.0.3 is missing. Anyone can help me ?
>
> --
> 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.

-- 
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] could anyone give me the source code of protobuffer 2.0.3

[minlujun]

My project is using this old version, but the source code of protobuffer 
2.0.3 is missing. Anyone can help me ?

-- 
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] Re: Compiler error with GCC targeting ARM - Atomic32 vs AtomicWord

['Feng Xiao' via Protocol Buffers]

Hi Brad, can you send your patch as a pull request? It's easier to review
the diff there.

On Wed, Aug 9, 2017 at 8:27 AM, Brad Larson  wrote:

>
>
> On Monday, August 7, 2017 at 1:13:46 PM UTC-5, Brad Larson wrote:
>>
>> Hello, I'm getting a compiler error when using GCC to target ARM
>> platforms.  I've patched this locally, but would like to upstream my patch
>> and am not sure on the best generally-acceptable solution.
>>
>> src/google/protobuf/io/coded_stream.h: In static
>> member function 'static bool google::protobuf::io::CodedOut
>> putStream::IsDefaultSerializationDeterministic()':
>> C:\projects\cycling\carlton\external\protobuf\src/google/pro
>> tobuf/io/coded_stream.h:868:53: error: invalid conversion from
>> 'google::protobuf::internal::AtomicWord* {aka int*}' to 'const volatile
>> Atomic32* {aka const volatile long int*}' [-fpermissive]
>>  return google::protobuf::internal::Acquire_Load(_serializat
>> ion_deterministic_);
>>
>>  ^
>>
>> On my platform, int32 is defined as long int and intptr_t is defined as
>> int (They both are 4 bytes).  This is causing the above error.
>>
>> Locally, I can easily change the type of Atomic32 to intptr_t or just int,
>> or change the type of AtomicWord to int32 or intptr_t.  But this isn't
>> generally acceptable of course.
>>
>> I'm not sure on what a better solution might be.  I see we already have a
>> check #if GOOGLE_PROTOBUF_ARCH_POWER to typedef Atomic32 to intptr_t in
>> some cases, and extra logic around #if defined(__ILP32__) ||
>> defined(GOOGLE_PROTOBUF_OS_NACL).  Could this be simplified with a #if
>> sizeof intptr_t == sizeof int32 check (or similar)?
>>
>> Very open to any suggestions on how to upstream a fix for this!
>>
>> Thanks,
>> Brad
>>
>
>
> If it is helpful, here are the current typedefs, from atomicops.h:
>
> #if defined(GOOGLE_PROTOBUF_ARCH_POWER)
> #if defined(_LP64) || defined(__LP64__)
> typedef int32 Atomic32;
> typedef intptr_t Atomic64;
> #else
> typedef intptr_t Atomic32;
> typedef int64 Atomic64;
> #endif
> #else
> typedef intptr_t Atomic32;
> #ifdef GOOGLE_PROTOBUF_ARCH_64_BIT
> // We need to be able to go between Atomic64 and AtomicWord implicitly.
> This
> // means Atomic64 and AtomicWord should be the same type on 64-bit.
> #if defined(__ILP32__) || defined(GOOGLE_PROTOBUF_OS_NACL)
> // NaCl's intptr_t is not actually 64-bits on 64-bit!
> // http://code.google.com/p/nativeclient/issues/detail?id=1162
> // sparcv9's pointer type is 32bits
> typedef int64 Atomic64;
> #else
> typedef intptr_t Atomic64;
> #endif
> #endif
> #endif
>
> // Use AtomicWord for a machine-sized pointer.  It will use the Atomic32 or
> // Atomic64 routines below, depending on your architecture.
> typedef intptr_t AtomicWord;
>
> --
> 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.
>

-- 
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] Re: Compiler error with GCC targeting ARM - Atomic32 vs AtomicWord

[Brad Larson]

On Monday, August 7, 2017 at 1:13:46 PM UTC-5, Brad Larson wrote:
>
> Hello, I'm getting a compiler error when using GCC to target ARM 
> platforms.  I've patched this locally, but would like to upstream my patch 
> and am not sure on the best generally-acceptable solution.
>
> src/google/protobuf/io/coded_stream.h: In static
> member function 'static bool 
> google::protobuf::io::CodedOutputStream::IsDefaultSerializationDeterministic()':
> C:\projects\cycling\carlton\external\protobuf\src/google/protobuf/io/coded_stream.h:868:53:
>  
> error: invalid conversion from 'google::protobuf::internal::AtomicWord* 
> {aka int*}' to 'const volatile
> Atomic32* {aka const volatile long int*}' [-fpermissive]
>  return 
> google::protobuf::internal::Acquire_Load(_serialization_deterministic_);
> 
>  ^
>
> On my platform, int32 is defined as long int and intptr_t is defined as 
> int (They both are 4 bytes).  This is causing the above error.
>
> Locally, I can easily change the type of Atomic32 to intptr_t or just int, 
> or change the type of AtomicWord to int32 or intptr_t.  But this isn't 
> generally acceptable of course.
>
> I'm not sure on what a better solution might be.  I see we already have a 
> check #if GOOGLE_PROTOBUF_ARCH_POWER to typedef Atomic32 to intptr_t in 
> some cases, and extra logic around #if defined(__ILP32__) || 
> defined(GOOGLE_PROTOBUF_OS_NACL).  Could this be simplified with a #if 
> sizeof intptr_t == sizeof int32 check (or similar)?
>
> Very open to any suggestions on how to upstream a fix for this!
>
> Thanks,
> Brad
>


If it is helpful, here are the current typedefs, from atomicops.h:

#if defined(GOOGLE_PROTOBUF_ARCH_POWER)
#if defined(_LP64) || defined(__LP64__)
typedef int32 Atomic32;
typedef intptr_t Atomic64;
#else
typedef intptr_t Atomic32;
typedef int64 Atomic64;
#endif
#else
typedef intptr_t Atomic32;
#ifdef GOOGLE_PROTOBUF_ARCH_64_BIT
// We need to be able to go between Atomic64 and AtomicWord implicitly. 
 This
// means Atomic64 and AtomicWord should be the same type on 64-bit.
#if defined(__ILP32__) || defined(GOOGLE_PROTOBUF_OS_NACL)
// NaCl's intptr_t is not actually 64-bits on 64-bit!
// http://code.google.com/p/nativeclient/issues/detail?id=1162
// sparcv9's pointer type is 32bits
typedef int64 Atomic64;
#else
typedef intptr_t Atomic64;
#endif
#endif
#endif

// Use AtomicWord for a machine-sized pointer.  It will use the Atomic32 or
// Atomic64 routines below, depending on your architecture.
typedef intptr_t AtomicWord; 

-- 
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] Protobuf member by member copy from java to protobuf class and vice versa

[Jay Sharma]

I have a question regarding "*Protocol buffer generated java class*". 
Is there is any way to customise it, so that I do not have to copy member 
by member for conversion from java object to protobuf object and vice-versa.

*For Instance:*

I have java class:

class Dummy{
 int id;
}


I have protocol buffer (.*proto*) file:

message Dummy{
required int id = 1;
}


Now, for converting the java object to the proto buf or vice versa ,I have 
to assign member by member to objects [java/protobuf].

In the above case for converting the java object [javaObj] to protobuf 
object [protoObj] :

 Dummy protoObj = null;
 Builder builder = ProtoDummy.Dummy.newBuilder();
 builder.setId(javaObj.getId());
 protoObj = builder.build();


Similarly, for coverting from protobuf to java object, I have to perform 
member by member copy.

Is there is a way to directly assign the object or faster way than the one 
I am using.

-- 
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.