Re: [protobuf] Re: Issue with protobuf-2.3.0: Problem running 'configure' on Solaris 10
No, you can't skip configuring the gtest directory.
But why does your gcc produce executables that can't be executed? Is it the
-m64 flag that breaks them?
On Thu, Mar 11, 2010 at 6:19 PM, stevenong2007 wrote:
> Hi,
>
> Thanks for your respond. Here is the excerpt from gtest/config.log
> that I think relevant to this issue...
>
> ***
> gcc version 4.2.3 (Ubuntu 4.2.3-2nexenta7)
> configure:2769: $? = 0
> configure:2776: gcc -V >&5
> gcc: '-V' option must have argument
> configure:2779: $? = 1
> configure:2802: checking for C compiler default output file name
> configure:2829: gcc -m64 conftest.c >&5
> configure:2832: $? = 0
> configure:2870: result: a.out
> configure:2887: checking whether the C compiler works
> configure:2897: ./a.out
> ./configure: line 2898: ./a.out: cannot execute binary file
> configure:2900: $? = 126
> configure:2909: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details.
> ***
>
> ...One more question: Is it possible to tell 'configure' to skip the
> 'gtest' directory? (I've tried '--without-gtest' and --'without-system-
> gtest' - neither work)
>
> Thanks in advance for your help.
> Steven
>
>
>
> On Mar 10, 11:18 pm, Kenton Varda wrote:
> > Oops, it looks like it's actually gtest/config.log that you need to look
> at,
> > since the failure happened when configuring the gtest sub-package.
> >
> > On Wed, Mar 10, 2010 at 7:44 PM, stevenong2007 >wrote:
> >
> >
> >
> > > I am running Nexenta (Debian on top of Solaris 11), and the gcc
> > > version is:
> >
> > > gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2nexenta7)
> > > Copyright (C) 2007 Free Software Foundation, Inc.
> > > This is free software; see the source for copying conditions. There
> > > is NO
> > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > > PURPOSE.
> >
> > >
> > > Also, here is the excerpt from config.log...
> >
> > > configure:16902: checking whether to check for GCC pthread/shared
> > > inconsistencies
> > > configure:16925: /usr/bin/gcc-4.2 -o conftest -shared -fPIC -Wl,-
> > > z,defs -m64 -D_REENTRANT -pthreads conftest.c >&5
> > > configure:16931: $? = 0
> > > configure:16952: result: yes
> > > configure:16958: checking whether -pthread is sufficient with -shared
> > > configure:16983: /usr/bin/gcc-4.2 -o conftest -shared -fPIC -Wl,-
> > > z,defs -m64 -D_REENTRANT -pthreads conftest.c >&5
> > > /var/tmp//cc9WaO7o.o: In function `main':
> > > conftest.c:(.text+0x11): undefined reference to `pthread_join'
> > > conftest.c:(.text+0x1b): undefined reference to `pthread_attr_init'
> > > conftest.c:(.text+0x20): undefined reference to `_getfp'
> > > conftest.c:(.text+0x36): undefined reference to
> > > `__pthread_cleanup_push'
> > > conftest.c:(.text+0x4f): undefined reference to `pthread_create'
> > > conftest.c:(.text+0x5d): undefined reference to
> > > `__pthread_cleanup_pop'
> > > collect2: ld returned 1 exit status
> > > configure:16989: $? = 1
> > > configure: failed program was:
> > > | /* confdefs.h. */
> > > | #define PACKAGE_NAME "Protocol Buffers"
> > > | #define PACKAGE_TARNAME "protobuf"
> > > | #define PACKAGE_VERSION "2.3.0"
> > > | #define PACKAGE_STRING "Protocol Buffers 2.3.0"
> > > | #define PACKAGE_BUGREPORT "protobuf@googlegroups.com"
> > > | #define PACKAGE "protobuf"
> > > | #define VERSION "2.3.0"
> > > | #define _GNU_SOURCE 1
> > > | #define STDC_HEADERS 1
> > > | #define HAVE_SYS_TYPES_H 1
> > > | #define HAVE_SYS_STAT_H 1
> > > | #define HAVE_STDLIB_H 1
> > > | #define HAVE_STRING_H 1
> > > | #define HAVE_MEMORY_H 1
> > > | #define HAVE_STRINGS_H 1
> > > | #define HAVE_INTTYPES_H 1
> > > | #define HAVE_STDINT_H 1
> > > | #define HAVE_UNISTD_H 1
> > > | #define __EXTENSIONS__ 1
> > > | #define _POSIX_PTHREAD_SEMANTICS 1
> > > | #define _TANDEM_SOURCE 1
> > > | #define HAVE_DLFCN_H 1
> > > | #define LT_OBJDIR ".libs/"
> > > | #define STDC_HEADERS 1
> > > | #define HAVE_FCNTL_H 1
> > > | #define HAVE_INTTYPES_H 1
> > > | #define HAVE_LIMITS_H 1
> > > | #define HAVE_STDLIB_H 1
> > > | #define HAVE_UNISTD_H 1
> > > | #define HAVE_FTRUNCATE 1
> > > | #define HAVE_MEMSET 1
> > > | #define HAVE_MKDIR 1
> > > | #define HAVE_STRCHR 1
> > > | #define HAVE_STRERROR 1
> > > | #define HAVE_STRTOL 1
> > > | /* end confdefs.h. */
> > > | #include
> > > | int
> > > | main ()
> > > | {
> > > | pthread_t th; pthread_join(th, 0);
> > > | pthread_attr_init(0); pthread_cleanup_push(0, 0);
> > > | pthread_create(0,0,0,0); pthread_cleanup_pop(0);
> > > | ;
> > > | return 0;
> > > | }
> > > configure:17010: result: no
> > > configure:17020: checking whether -lpthread fixes that
> > > configure:17046: /usr/bin/gcc-4.2 -o conftest -shared -fPIC -Wl,-
> > > z,defs -m64 -D_REENTRANT -pthreads conftest.c -lpthread >&5
> > > configure:17052: $? = 0
> > > configure:17070: result: yes
> > > configure:17179: checking the location of hash_map
> > > configu
[protobuf] Re: Issue with protobuf-2.3.0: Problem running 'configure' on Solaris 10
Hi,
Thanks for your respond. Here is the excerpt from gtest/config.log
that I think relevant to this issue...
***
gcc version 4.2.3 (Ubuntu 4.2.3-2nexenta7)
configure:2769: $? = 0
configure:2776: gcc -V >&5
gcc: '-V' option must have argument
configure:2779: $? = 1
configure:2802: checking for C compiler default output file name
configure:2829: gcc -m64 conftest.c >&5
configure:2832: $? = 0
configure:2870: result: a.out
configure:2887: checking whether the C compiler works
configure:2897: ./a.out
./configure: line 2898: ./a.out: cannot execute binary file
configure:2900: $? = 126
configure:2909: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
***
...One more question: Is it possible to tell 'configure' to skip the
'gtest' directory? (I've tried '--without-gtest' and --'without-system-
gtest' - neither work)
Thanks in advance for your help.
Steven
On Mar 10, 11:18 pm, Kenton Varda wrote:
> Oops, it looks like it's actually gtest/config.log that you need to look at,
> since the failure happened when configuring the gtest sub-package.
>
> On Wed, Mar 10, 2010 at 7:44 PM, stevenong2007 wrote:
>
>
>
> > I am running Nexenta (Debian on top of Solaris 11), and the gcc
> > version is:
>
> > gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2nexenta7)
> > Copyright (C) 2007 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions. There
> > is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
>
> >
> > Also, here is the excerpt from config.log...
>
> > configure:16902: checking whether to check for GCC pthread/shared
> > inconsistencies
> > configure:16925: /usr/bin/gcc-4.2 -o conftest -shared -fPIC -Wl,-
> > z,defs -m64 -D_REENTRANT -pthreads conftest.c >&5
> > configure:16931: $? = 0
> > configure:16952: result: yes
> > configure:16958: checking whether -pthread is sufficient with -shared
> > configure:16983: /usr/bin/gcc-4.2 -o conftest -shared -fPIC -Wl,-
> > z,defs -m64 -D_REENTRANT -pthreads conftest.c >&5
> > /var/tmp//cc9WaO7o.o: In function `main':
> > conftest.c:(.text+0x11): undefined reference to `pthread_join'
> > conftest.c:(.text+0x1b): undefined reference to `pthread_attr_init'
> > conftest.c:(.text+0x20): undefined reference to `_getfp'
> > conftest.c:(.text+0x36): undefined reference to
> > `__pthread_cleanup_push'
> > conftest.c:(.text+0x4f): undefined reference to `pthread_create'
> > conftest.c:(.text+0x5d): undefined reference to
> > `__pthread_cleanup_pop'
> > collect2: ld returned 1 exit status
> > configure:16989: $? = 1
> > configure: failed program was:
> > | /* confdefs.h. */
> > | #define PACKAGE_NAME "Protocol Buffers"
> > | #define PACKAGE_TARNAME "protobuf"
> > | #define PACKAGE_VERSION "2.3.0"
> > | #define PACKAGE_STRING "Protocol Buffers 2.3.0"
> > | #define PACKAGE_BUGREPORT "protobuf@googlegroups.com"
> > | #define PACKAGE "protobuf"
> > | #define VERSION "2.3.0"
> > | #define _GNU_SOURCE 1
> > | #define STDC_HEADERS 1
> > | #define HAVE_SYS_TYPES_H 1
> > | #define HAVE_SYS_STAT_H 1
> > | #define HAVE_STDLIB_H 1
> > | #define HAVE_STRING_H 1
> > | #define HAVE_MEMORY_H 1
> > | #define HAVE_STRINGS_H 1
> > | #define HAVE_INTTYPES_H 1
> > | #define HAVE_STDINT_H 1
> > | #define HAVE_UNISTD_H 1
> > | #define __EXTENSIONS__ 1
> > | #define _POSIX_PTHREAD_SEMANTICS 1
> > | #define _TANDEM_SOURCE 1
> > | #define HAVE_DLFCN_H 1
> > | #define LT_OBJDIR ".libs/"
> > | #define STDC_HEADERS 1
> > | #define HAVE_FCNTL_H 1
> > | #define HAVE_INTTYPES_H 1
> > | #define HAVE_LIMITS_H 1
> > | #define HAVE_STDLIB_H 1
> > | #define HAVE_UNISTD_H 1
> > | #define HAVE_FTRUNCATE 1
> > | #define HAVE_MEMSET 1
> > | #define HAVE_MKDIR 1
> > | #define HAVE_STRCHR 1
> > | #define HAVE_STRERROR 1
> > | #define HAVE_STRTOL 1
> > | /* end confdefs.h. */
> > | #include
> > | int
> > | main ()
> > | {
> > | pthread_t th; pthread_join(th, 0);
> > | pthread_attr_init(0); pthread_cleanup_push(0, 0);
> > | pthread_create(0,0,0,0); pthread_cleanup_pop(0);
> > | ;
> > | return 0;
> > | }
> > configure:17010: result: no
> > configure:17020: checking whether -lpthread fixes that
> > configure:17046: /usr/bin/gcc-4.2 -o conftest -shared -fPIC -Wl,-
> > z,defs -m64 -D_REENTRANT -pthreads conftest.c -lpthread >&5
> > configure:17052: $? = 0
> > configure:17070: result: yes
> > configure:17179: checking the location of hash_map
> > configure:17223: g++ -c -g -DNDEBUG -m64 conftest.cpp >&5
> > configure:17229: $? = 0
> > configure:17287: result:
> > configure:17456: creating ./config.status
>
> > ## -- ##
> > ## Running config.status. ##
> > ## -- ##
>
> > This file was extended by Protocol Buffers config.status 2.3.0, which
> > was
> > generated by GNU Autoconf 2.61. Invocation command line was
>
> > CONFIG_FILES =
> > CONFIG_HEADERS =
> > CONFIG_LINK
Re: [protobuf] Support for J2ME
What exactly is deprecated in the services API? Is it only the Service and BlockingService interfaces? On Thu, Mar 11, 2010 at 6:52 PM, Igor Gatis wrote: > *- Why did you eliminate the builder pattern?* > > To save jar space. J2ME environment is pretty restricted. Many devices have > a few kilo bytes size limit (e.g 128K, 256K). An empty class adds about 200 > bytes to jar file. The long time I worked with J2ME convinced me the less > classes the better. I tried to keep it as simple as possible without hurting > the OO design. > > *- Why did you choose to implement generic services when this feature is > deprecated anyway?* > > That was overseen. I need to fix that then. > > *Your diff shows the runtime classes as if they were completely new. > Could you re-arrange the files so that it actually compares your versions > of these classes against the official ones?* > > The some official java sources are not Java 1.3 compatible (for instance, > they use generics and for-each loops). I've also flattened some of the > classes hierarchy (e.g. Message vs AbstractMessage + GeneratedMessage + > MessageLite, etc) to save jar space. I've also removed dependency to > Descriptors so I had to change BlockingRpcChannel and RpcChannel to receive > the method as a String rather than a descriptor. So that being said, the new > set of files are tailored to J2ME environment and its limitations. > > So the bottom line is that I had to squeeze the runtime to get it as small > as possible - this is a fully functional protobuf runtime implementation > that occupies 26KB against 173KB of standard Java implementation. > > Does that make sense? > > On Thu, Mar 11, 2010 at 4:20 PM, Kenton Varda wrote: > >> Can you explain some of the design decisions: >> >> - Why did you eliminate the builder pattern? >> >> - Why did you choose to implement generic services when this feature is >> deprecated anyway? >> >> Your diff shows the runtime classes as if they were completely new. Could >> you re-arrange the files so that it actually compares your versions of these >> classes against the official ones? >> >> = >> >> As far as making this part of the official project, my worry is about >> maintenance challenges. It will be much harder for us to make changes to >> the code generator if we always have to consider J2ME. For example, when >> coupled changes to the code generator and runtime library, unless the change >> is in a part that doesn't apply to J2ME, we would now have to update the >> J2ME library too. Not only does this require modifying more files, but it >> requires setting up J2ME tools for testing -- and our internal build system >> does not have any support for this AFAIK. >> >> So my thought is that the best way to run this is as a branch. Changes to >> the official implementation would not affect J2ME until the J2ME branch >> maintainers choose to update it, and then they could make sure those changes >> make sense. >> >> On Thu, Mar 11, 2010 at 9:16 AM, Igor Gatis wrote: >> >>> Here is the code review: http://codereview.appspot.com/445041/show >>> >>> >>> On Thu, Mar 11, 2010 at 2:09 PM, Igor Gatis wrote: >>> It is a stripped copy of the official Java implementation. Here are the list of files: BlockingRpcChannel.java BlockingService.java ByteString.java CodedInputStream.java CodedOutputStream.java InvalidProtocolBufferException.java Message.java RpcCallback.java RpcChannel.java RpcController.java ServiceException.java WireFormat.java Limitations: 1) Biggest limitation is the lack of support for extensions. I plan to fix it soon. 2) Also, for J2ME devices, (asynchronous) Services is not a huge requirement, so it is not there too (notice there is no Service.java in this list). As for the compiler, there is A LOT of shared code. I'm sending you a code review. Thanks, -Gatis On Wed, Mar 10, 2010 at 1:17 AM, Kenton Varda wrote: > Is your implementation a modification of the official Java > implementation? If so, how much is shared? Could you send me a diff via > codereview.appspot.com? > > On Tue, Mar 9, 2010 at 5:46 PM, Igor Gatis wrote: > >> So it is totally out of the scope of this project to add such support? >> >> The changes I've made seem to match with the current >> architecture. I've added extended protoc to accept a new file option >> java_platform (where user may specify J2SE(default) or J2ME) which makes >> it >> produce J2ME compatible sources. >> >> On Tue, Mar 9, 2010 at 10:29 PM, Kenton Varda wrote: >> >>> There are three J2ME implementations on the third-party list: >>> http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns >>> >>> I'd be happy to list yours as well if you'd like. >>> >>> On Tue, Mar 9, 2010 at 5:17 PM, Igor Gatis wrote: >>
Re: [protobuf] Support for J2ME
*- Why did you eliminate the builder pattern?* To save jar space. J2ME environment is pretty restricted. Many devices have a few kilo bytes size limit (e.g 128K, 256K). An empty class adds about 200 bytes to jar file. The long time I worked with J2ME convinced me the less classes the better. I tried to keep it as simple as possible without hurting the OO design. *- Why did you choose to implement generic services when this feature is deprecated anyway?* That was overseen. I need to fix that then. *Your diff shows the runtime classes as if they were completely new. Could you re-arrange the files so that it actually compares your versions of these classes against the official ones?* The some official java sources are not Java 1.3 compatible (for instance, they use generics and for-each loops). I've also flattened some of the classes hierarchy (e.g. Message vs AbstractMessage + GeneratedMessage + MessageLite, etc) to save jar space. I've also removed dependency to Descriptors so I had to change BlockingRpcChannel and RpcChannel to receive the method as a String rather than a descriptor. So that being said, the new set of files are tailored to J2ME environment and its limitations. So the bottom line is that I had to squeeze the runtime to get it as small as possible - this is a fully functional protobuf runtime implementation that occupies 26KB against 173KB of standard Java implementation. Does that make sense? On Thu, Mar 11, 2010 at 4:20 PM, Kenton Varda wrote: > Can you explain some of the design decisions: > > - Why did you eliminate the builder pattern? > > - Why did you choose to implement generic services when this feature is > deprecated anyway? > > Your diff shows the runtime classes as if they were completely new. Could > you re-arrange the files so that it actually compares your versions of these > classes against the official ones? > > = > > As far as making this part of the official project, my worry is about > maintenance challenges. It will be much harder for us to make changes to > the code generator if we always have to consider J2ME. For example, when > coupled changes to the code generator and runtime library, unless the change > is in a part that doesn't apply to J2ME, we would now have to update the > J2ME library too. Not only does this require modifying more files, but it > requires setting up J2ME tools for testing -- and our internal build system > does not have any support for this AFAIK. > > So my thought is that the best way to run this is as a branch. Changes to > the official implementation would not affect J2ME until the J2ME branch > maintainers choose to update it, and then they could make sure those changes > make sense. > > On Thu, Mar 11, 2010 at 9:16 AM, Igor Gatis wrote: > >> Here is the code review: http://codereview.appspot.com/445041/show >> >> >> On Thu, Mar 11, 2010 at 2:09 PM, Igor Gatis wrote: >> >>> It is a stripped copy of the official Java implementation. Here are the >>> list of files: >>> >>> BlockingRpcChannel.java >>> BlockingService.java >>> ByteString.java >>> CodedInputStream.java >>> CodedOutputStream.java >>> InvalidProtocolBufferException.java >>> Message.java >>> RpcCallback.java >>> RpcChannel.java >>> RpcController.java >>> ServiceException.java >>> WireFormat.java >>> >>> Limitations: >>> 1) Biggest limitation is the lack of support for extensions. I plan to >>> fix it soon. >>> 2) Also, for J2ME devices, (asynchronous) Services is not a huge >>> requirement, so it is not there too (notice there is no Service.java in this >>> list). >>> >>> As for the compiler, there is A LOT of shared code. >>> >>> I'm sending you a code review. >>> >>> Thanks, >>> -Gatis >>> >>> On Wed, Mar 10, 2010 at 1:17 AM, Kenton Varda wrote: >>> Is your implementation a modification of the official Java implementation? If so, how much is shared? Could you send me a diff via codereview.appspot.com? On Tue, Mar 9, 2010 at 5:46 PM, Igor Gatis wrote: > So it is totally out of the scope of this project to add such support? > > The changes I've made seem to match with the current architecture. I've > added extended protoc to accept a new file option java_platform (where > user > may specify J2SE(default) or J2ME) which makes it produce J2ME compatible > sources. > > On Tue, Mar 9, 2010 at 10:29 PM, Kenton Varda wrote: > >> There are three J2ME implementations on the third-party list: >> http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns >> >> I'd be happy to list yours as well if you'd like. >> >> On Tue, Mar 9, 2010 at 5:17 PM, Igor Gatis wrote: >> >>> Hi protobuf team, >>> >>> Have you guys considered supporting J2ME? >>> >>> I've extended protoc to generate J2ME compatible code and built its >>> supporting J2ME runtime library. I was wondering if you guys would >>> consider >>> reviewing my changes. >>> >>
Re: [protobuf] Disabling the 'gen_cpp' output of Services?
Cool. If you like, feel free to propose a modification to the standard code
generator which makes the file descriptor pointer directly accessible, so
that you don't have to have the extra lookup step.
On Thu, Mar 11, 2010 at 11:58 AM, Andrew Kimpton wrote:
>
>
> On Thu, Mar 11, 2010 at 2:27 PM, Kenton Varda wrote:
>
>> On the first call to your descriptor() or GetDescriptor() method, you
>> could look up the ServiceDescriptor in
>> google::protobuf::DescriptorPool::generated_pool().
>>
>
> I think that's what my generated code is essentially now doing :
>
> In my generated service_subclass::descriptor() and ::GetDescriptor()
> methods I call a 'protobuf_rpc_AssignDescriptorsOnce()' function that looks
> like this :
>
> void protobuf_rpc_AssignDesc_test_5fservice_2eproto() {
> const ::google::protobuf::FileDescriptor* file =
> ::google::protobuf::DescriptorPool::generated_pool()->FindFileByName(
> "test_service.proto");
> GOOGLE_CHECK(file != NULL);
> TestingService_descriptor_ = file->service(0);
> }
>
> GOOGLE_PROTOBUF_DECLARE_ONCE(protobuf_rpc_AssignDescriptors_once_);
> inline void protobuf_rpc_AssignDescriptorsOnce() {
> ::google::protobuf::GoogleOnceInit(&protobuf_rpc_AssignDescriptors_once_,
> &protobuf_rpc_AssignDesc_test_5fservice_2eproto);
>
> Andrew 8-)
>
--
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: [protobuf] protobuf license terms
The license is displayed prominently on the project page as well as in the file COPYING.txt which comes with the source package. It is the New BSD license. http://www.opensource.org/licenses/bsd-license.php On Thu, Mar 11, 2010 at 11:56 AM, n179911 wrote: > Hi protobuf team, > > Can you please tell me what is the license term for protobuf project? > > Thank you. > > -- > 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.
Re: [protobuf] Re: Problem : Serialized in protobuf-net, deserialize in C++ app
Please keep the mailing list CC'd so that others can help.
The input_ field is normally null when parsing from a flat array, so that's
not the problem.
ReadBytes() is an inline function found in
google/protobuf/wire_format_lite_inl.h. Your debugger should be able to
descend into it. You may have to compile with optimization disabled so that
it doesn't actually inline the function.
On Thu, Mar 11, 2010 at 12:11 PM, Roey Lehman wrote:
> Hi Kenton, thanks for the reply.
>
> this line causes the access violation :
> DO_(::google::protobuf::internal::WireFormatLite::ReadBytes(input,
> this->mutable_data()));
>
> I checked this in the debugger. This-> , is not null, and is the message
> object itself.
>
> Input is a CodedInputStream type, and it is not null either.
> I haven't the code for ReadBytes, I don't know what goes on inside it, but
> I can tell you that the "input_" field of the CodedInputStream, is null.
> (the "buffer_" field is not null ).
>
> since I can't delve into ReadBytes, I have no idea what's causing the
> access violation
>
>
>
> On Thu, Mar 11, 2010 at 9:44 PM, Kenton Varda wrote:
>
>> OK, so, which pointer is null?
>>
>> We can't do this for you. You are the only one who can run your code in
>> the debugger.
>>
>> If you want us to debug it, you need to provide a small, self-contained
>> example program demonstrating the problem. Just C++ code and input data is
>> needed -- the C# part is not necessary.
>>
>> On Thu, Mar 11, 2010 at 5:56 AM, Roey wrote:
>>
>>> Just to clarify , the access violation occurs inside the
>>> ParseFromArray function, right when it tries to parse the second field
>>> of the struct ("data"),
>>> this is the code that crashes inside the cc file :
>>>
>>> // optional bytes Data = 2;
>>> case 2: {
>>>if
>>> (::google::protobuf::internal::WireFormatLite::GetTagWireType(tag) ==
>>>
>>> ::google::protobuf::internal::WireFormatLite::WIRETYPE_LENGTH_DELIMITED)
>>> {
>>> parse_Data:
>>>
>>> DO_(::google::protobuf::internal::WireFormatLite::ReadBytes(
>>> <--
>>> This crashes
>>>input, this->mutable_data()));
>>>
>>>
>>> --
>>> 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] protobuf license terms
Hi protobuf team, Can you please tell me what is the license term for protobuf project? Thank you. -- 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: [protobuf] Disabling the 'gen_cpp' output of Services?
On Thu, Mar 11, 2010 at 2:27 PM, Kenton Varda wrote:
> On the first call to your descriptor() or GetDescriptor() method, you could
> look up the ServiceDescriptor in
> google::protobuf::DescriptorPool::generated_pool().
>
I think that's what my generated code is essentially now doing :
In my generated service_subclass::descriptor() and ::GetDescriptor() methods
I call a 'protobuf_rpc_AssignDescriptorsOnce()' function that looks like
this :
void protobuf_rpc_AssignDesc_test_5fservice_2eproto() {
const ::google::protobuf::FileDescriptor* file =
::google::protobuf::DescriptorPool::generated_pool()->FindFileByName(
"test_service.proto");
GOOGLE_CHECK(file != NULL);
TestingService_descriptor_ = file->service(0);
}
GOOGLE_PROTOBUF_DECLARE_ONCE(protobuf_rpc_AssignDescriptors_once_);
inline void protobuf_rpc_AssignDescriptorsOnce() {
::google::protobuf::GoogleOnceInit(&protobuf_rpc_AssignDescriptors_once_,
&protobuf_rpc_AssignDesc_test_5fservice_2eproto);
Andrew 8-)
--
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: [protobuf] Re: Problem : Serialized in protobuf-net, deserialize in C++ app
OK, so, which pointer is null?
We can't do this for you. You are the only one who can run your code in the
debugger.
If you want us to debug it, you need to provide a small, self-contained
example program demonstrating the problem. Just C++ code and input data is
needed -- the C# part is not necessary.
On Thu, Mar 11, 2010 at 5:56 AM, Roey wrote:
> Just to clarify , the access violation occurs inside the
> ParseFromArray function, right when it tries to parse the second field
> of the struct ("data"),
> this is the code that crashes inside the cc file :
>
> // optional bytes Data = 2;
> case 2: {
>if
> (::google::protobuf::internal::WireFormatLite::GetTagWireType(tag) ==
>
> ::google::protobuf::internal::WireFormatLite::WIRETYPE_LENGTH_DELIMITED)
> {
> parse_Data:
>
> DO_(::google::protobuf::internal::WireFormatLite::ReadBytes(
> <--
> This crashes
>input, this->mutable_data()));
>
>
> --
> 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.
Re: [protobuf] Re: Disabling the 'gen_cpp' output of Services?
On Thu, Mar 11, 2010 at 11:29 AM, Kenton Varda wrote: > On Thu, Mar 11, 2010 at 8:01 AM, NoamC wrote: > >> 1. Why was the current method of services deprecated? will it be >> removed in the future? >> > > It's deprecated in favor of code generator plugins. It will probably never > be removed. > To be clear, it won't be removed because too many people use it. But we strongly advise against new users. -- 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: [protobuf] Re: Disabling the 'gen_cpp' output of Services?
On Thu, Mar 11, 2010 at 8:01 AM, NoamC wrote: > I am looking for a lightweight RPC in C/C++ between VxWorks and linux > (both embedded systems) and started looking at protobuf for this > purpose. > > The 3rd party addons (RPC implementations) I saw in the doc looks > either heavy (RCF) or immature. > > 1. Why was the current method of services deprecated? will it be > removed in the future? > It's deprecated in favor of code generator plugins. It will probably never be removed. > 2. are there examples how to write plugins? skeletal RPC using this > method? > It sounds like Andrew will have an example soon. :) There is also my incomplete Java RPC system: http://capnproto.googlecode.com http://code.google.com/p/capnproto/source/browse/compiler/protoc-gen-capnproto-java.cc I haven't been able to work on it in awhile, unfortunately. 3. Any contemporary recommended RPC implementation ? > I haven't tried any of the third-party implementations. -- 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: [protobuf] Disabling the 'gen_cpp' output of Services?
On the first call to your descriptor() or GetDescriptor() method, you could look up the ServiceDescriptor in google::protobuf::DescriptorPool::generated_pool(). Alternatively, we could add a (public) way to directly fetch the file's FileDescriptor, then your descriptor getter could simply return "file->service($index$)". I'd rather hide the details of descriptor initialization from plugins as it's something that has changed many times and could change again. On Thu, Mar 11, 2010 at 11:07 AM, Andrew Kimpton wrote: > > > On Wed, Mar 10, 2010 at 8:50 PM, Kenton Varda wrote: > >> Note that to write your plugin, you do *not* have to copy the CppGenerator >> sources. Instead, write your plugin to use >> output_directory->OpenForInsert() to insert additional code into what the >> C++ code generator already generated. Specifically, you want to insert at >> the "namespace_scope" insertion point, documented here: >> >> >> http://code.google.com/apis/protocolbuffers/docs/reference/cpp-generated.html#plugins >> >> Then you would invoke protoc like: >> >> protoc --cpp_out=dir --my_plugin_out=dir foo.proto >> >> The C++ generator will be executed first, then your plugin. Since they >> have the same output location, your plugin can insert into the code >> generated by the C++ code generator. >> >> This is working pretty well - with one exception : > > My simple test_service.proto has a pair of messages (Request, Response) and > a single service that takes one and returns the other. > > A 'generic' services cpp output includes a global const pointer for the > ServiceDescriptor and a call to initialize that pointer in the 'AssignDesc' > generated method. If I turn off the generic output those two calls aren't > output - but I'd rather like them to be since it gives me a global instance > of the descriptor that I (expect) will help with 'discovery' and > 'registration' in the server side of the RPC. > > There doesn't seem to be a handy insertion point already present in the > file that I can use to inject my output, am I missing something ? Should I > file a bug ? > > As a workaround I can introduce my own initializer to initialize these > pieces but I still don't see a way to get it to be called from the > GoogleOnceInit() call in $file$_AssignDescriptorsOnce() method. > > I guess a third alternative would be to have my plugin generated > implementation of the Service subclass' descriptor() and GetDescriptor() > method just do the one time initialization of the global prior to returning > it ? Perhaps this is the best approach ? > > Andrew 8-) > > > -- 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: [protobuf] Support for J2ME
Can you explain some of the design decisions: - Why did you eliminate the builder pattern? - Why did you choose to implement generic services when this feature is deprecated anyway? Your diff shows the runtime classes as if they were completely new. Could you re-arrange the files so that it actually compares your versions of these classes against the official ones? = As far as making this part of the official project, my worry is about maintenance challenges. It will be much harder for us to make changes to the code generator if we always have to consider J2ME. For example, when coupled changes to the code generator and runtime library, unless the change is in a part that doesn't apply to J2ME, we would now have to update the J2ME library too. Not only does this require modifying more files, but it requires setting up J2ME tools for testing -- and our internal build system does not have any support for this AFAIK. So my thought is that the best way to run this is as a branch. Changes to the official implementation would not affect J2ME until the J2ME branch maintainers choose to update it, and then they could make sure those changes make sense. On Thu, Mar 11, 2010 at 9:16 AM, Igor Gatis wrote: > Here is the code review: http://codereview.appspot.com/445041/show > > > On Thu, Mar 11, 2010 at 2:09 PM, Igor Gatis wrote: > >> It is a stripped copy of the official Java implementation. Here are the >> list of files: >> >> BlockingRpcChannel.java >> BlockingService.java >> ByteString.java >> CodedInputStream.java >> CodedOutputStream.java >> InvalidProtocolBufferException.java >> Message.java >> RpcCallback.java >> RpcChannel.java >> RpcController.java >> ServiceException.java >> WireFormat.java >> >> Limitations: >> 1) Biggest limitation is the lack of support for extensions. I plan to fix >> it soon. >> 2) Also, for J2ME devices, (asynchronous) Services is not a huge >> requirement, so it is not there too (notice there is no Service.java in this >> list). >> >> As for the compiler, there is A LOT of shared code. >> >> I'm sending you a code review. >> >> Thanks, >> -Gatis >> >> On Wed, Mar 10, 2010 at 1:17 AM, Kenton Varda wrote: >> >>> Is your implementation a modification of the official Java >>> implementation? If so, how much is shared? Could you send me a diff via >>> codereview.appspot.com? >>> >>> On Tue, Mar 9, 2010 at 5:46 PM, Igor Gatis wrote: >>> So it is totally out of the scope of this project to add such support? The changes I've made seem to match with the current architecture. I've added extended protoc to accept a new file option java_platform (where user may specify J2SE(default) or J2ME) which makes it produce J2ME compatible sources. On Tue, Mar 9, 2010 at 10:29 PM, Kenton Varda wrote: > There are three J2ME implementations on the third-party list: > http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns > > I'd be happy to list yours as well if you'd like. > > On Tue, Mar 9, 2010 at 5:17 PM, Igor Gatis wrote: > >> Hi protobuf team, >> >> Have you guys considered supporting J2ME? >> >> I've extended protoc to generate J2ME compatible code and built its >> supporting J2ME runtime library. I was wondering if you guys would >> consider >> reviewing my changes. >> >> Thanks, >> -Gatis >> >> -- >> 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.
Re: [protobuf] Disabling the 'gen_cpp' output of Services?
On Wed, Mar 10, 2010 at 8:50 PM, Kenton Varda wrote: > Note that to write your plugin, you do *not* have to copy the CppGenerator > sources. Instead, write your plugin to use > output_directory->OpenForInsert() to insert additional code into what the > C++ code generator already generated. Specifically, you want to insert at > the "namespace_scope" insertion point, documented here: > > > http://code.google.com/apis/protocolbuffers/docs/reference/cpp-generated.html#plugins > > Then you would invoke protoc like: > > protoc --cpp_out=dir --my_plugin_out=dir foo.proto > > The C++ generator will be executed first, then your plugin. Since they > have the same output location, your plugin can insert into the code > generated by the C++ code generator. > > This is working pretty well - with one exception : My simple test_service.proto has a pair of messages (Request, Response) and a single service that takes one and returns the other. A 'generic' services cpp output includes a global const pointer for the ServiceDescriptor and a call to initialize that pointer in the 'AssignDesc' generated method. If I turn off the generic output those two calls aren't output - but I'd rather like them to be since it gives me a global instance of the descriptor that I (expect) will help with 'discovery' and 'registration' in the server side of the RPC. There doesn't seem to be a handy insertion point already present in the file that I can use to inject my output, am I missing something ? Should I file a bug ? As a workaround I can introduce my own initializer to initialize these pieces but I still don't see a way to get it to be called from the GoogleOnceInit() call in $file$_AssignDescriptorsOnce() method. I guess a third alternative would be to have my plugin generated implementation of the Service subclass' descriptor() and GetDescriptor() method just do the one time initialization of the global prior to returning it ? Perhaps this is the best approach ? Andrew 8-) -- 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: [protobuf] Support for J2ME
Here is the code review: http://codereview.appspot.com/445041/show On Thu, Mar 11, 2010 at 2:09 PM, Igor Gatis wrote: > It is a stripped copy of the official Java implementation. Here are the > list of files: > > BlockingRpcChannel.java > BlockingService.java > ByteString.java > CodedInputStream.java > CodedOutputStream.java > InvalidProtocolBufferException.java > Message.java > RpcCallback.java > RpcChannel.java > RpcController.java > ServiceException.java > WireFormat.java > > Limitations: > 1) Biggest limitation is the lack of support for extensions. I plan to fix > it soon. > 2) Also, for J2ME devices, (asynchronous) Services is not a huge > requirement, so it is not there too (notice there is no Service.java in this > list). > > As for the compiler, there is A LOT of shared code. > > I'm sending you a code review. > > Thanks, > -Gatis > > On Wed, Mar 10, 2010 at 1:17 AM, Kenton Varda wrote: > >> Is your implementation a modification of the official Java implementation? >> If so, how much is shared? Could you send me a diff via >> codereview.appspot.com? >> >> On Tue, Mar 9, 2010 at 5:46 PM, Igor Gatis wrote: >> >>> So it is totally out of the scope of this project to add such support? >>> >>> The changes I've made seem to match with the current architecture. I've >>> added extended protoc to accept a new file option java_platform (where user >>> may specify J2SE(default) or J2ME) which makes it produce J2ME compatible >>> sources. >>> >>> On Tue, Mar 9, 2010 at 10:29 PM, Kenton Varda wrote: >>> There are three J2ME implementations on the third-party list: http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns I'd be happy to list yours as well if you'd like. On Tue, Mar 9, 2010 at 5:17 PM, Igor Gatis wrote: > Hi protobuf team, > > Have you guys considered supporting J2ME? > > I've extended protoc to generate J2ME compatible code and built its > supporting J2ME runtime library. I was wondering if you guys would > consider > reviewing my changes. > > Thanks, > -Gatis > > -- > 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.
Re: [protobuf] Support for J2ME
It is a stripped copy of the official Java implementation. Here are the list of files: BlockingRpcChannel.java BlockingService.java ByteString.java CodedInputStream.java CodedOutputStream.java InvalidProtocolBufferException.java Message.java RpcCallback.java RpcChannel.java RpcController.java ServiceException.java WireFormat.java Limitations: 1) Biggest limitation is the lack of support for extensions. I plan to fix it soon. 2) Also, for J2ME devices, (asynchronous) Services is not a huge requirement, so it is not there too (notice there is no Service.java in this list). As for the compiler, there is A LOT of shared code. I'm sending you a code review. Thanks, -Gatis On Wed, Mar 10, 2010 at 1:17 AM, Kenton Varda wrote: > Is your implementation a modification of the official Java implementation? > If so, how much is shared? Could you send me a diff via > codereview.appspot.com? > > On Tue, Mar 9, 2010 at 5:46 PM, Igor Gatis wrote: > >> So it is totally out of the scope of this project to add such support? >> >> The changes I've made seem to match with the current architecture. I've >> added extended protoc to accept a new file option java_platform (where user >> may specify J2SE(default) or J2ME) which makes it produce J2ME compatible >> sources. >> >> On Tue, Mar 9, 2010 at 10:29 PM, Kenton Varda wrote: >> >>> There are three J2ME implementations on the third-party list: >>> http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns >>> >>> I'd be happy to list yours as well if you'd like. >>> >>> On Tue, Mar 9, 2010 at 5:17 PM, Igor Gatis wrote: >>> Hi protobuf team, Have you guys considered supporting J2ME? I've extended protoc to generate J2ME compatible code and built its supporting J2ME runtime library. I was wondering if you guys would consider reviewing my changes. Thanks, -Gatis -- 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: Disabling the 'gen_cpp' output of Services?
I am looking for a lightweight RPC in C/C++ between VxWorks and linux (both embedded systems) and started looking at protobuf for this purpose. The 3rd party addons (RPC implementations) I saw in the doc looks either heavy (RCF) or immature. 1. Why was the current method of services deprecated? will it be removed in the future? 2. are there examples how to write plugins? skeletal RPC using this method? 3. Any contemporary recommended RPC implementation ? thanks Noam On Mar 10, 11:55 pm, awk wrote: > I'm trying to throw together an alternativeRPCmechanism using a > protoc plugin/CodeGenerator (rather than use the deprecated headers). > -- 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: Problem : Serialized in protobuf-net, deserialize in C++ app
Just to clarify , the access violation occurs inside the
ParseFromArray function, right when it tries to parse the second field
of the struct ("data"),
this is the code that crashes inside the cc file :
// optional bytes Data = 2;
case 2: {
if
(::google::protobuf::internal::WireFormatLite::GetTagWireType(tag) ==
::google::protobuf::internal::WireFormatLite::WIRETYPE_LENGTH_DELIMITED)
{
parse_Data:
DO_(::google::protobuf::internal::WireFormatLite::ReadBytes(<--
This crashes
input, this->mutable_data()));
--
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: Problem : Serialized in protobuf-net, deserialize in C++ app
The crash occurs in my auto-generated cc file for the google proto
structs , on this line :
// optional bytes Data = 2;
case 2: {
if
(::google::protobuf::internal::WireFormatLite::GetTagWireType(tag) ==
::google::protobuf::internal::WireFormatLite::WIRETYPE_LENGTH_DELIMITED)
{
parse_Data:
DO_(::google::protobuf::internal::WireFormatLite::ReadBytes(
<---
crash occurs here
input, this->mutable_data()));
I do not know what this macro/code is trying to do (I guess it's
trying to deserialize my data field)
On Mar 11, 4:24 pm, Michael Poole wrote:
> Roey writes:
>
> [snip]
>
> > The problem is, I get a memory access violation when I try to
> > deserialize it :(
> > Unhandled exception at 0x02f166d8 in wmplayer.exe: 0xC005: Access
> > violation writing location 0x.
>
> > Are any of the things I'm doing here wrong , for what I'm trying to do
> > (serialize in C# .NET and deserialize in C++?)
>
> Most likely yes, but it's hard to suggest what that is without a brief
> code example that shows the crash. The crash is obviously trying to
> write into a null pointer, but only you can find out what code is at
> address 0x02f166d8.
>
> 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.
Re: [protobuf] Problem : Serialized in protobuf-net, deserialize in C++ app
Hmm - the data field should be pretty trivial - in terms of the wire-format it is just a field-header, a length-prefix, and then the raw data. How big is the message when serialized? (or: how big is a short message that reproduces this problem?) Could you possibly both the BLOB, either in hex or base-64, so that I can see what the bytes are? On 11 March 2010 14:24, Michael Poole wrote: > Roey writes: > > [snip] > > The problem is, I get a memory access violation when I try to > > deserialize it :( > > Unhandled exception at 0x02f166d8 in wmplayer.exe: 0xC005: Access > > violation writing location 0x. > > > > Are any of the things I'm doing here wrong , for what I'm trying to do > > (serialize in C# .NET and deserialize in C++?) > > Most likely yes, but it's hard to suggest what that is without a brief > code example that shows the crash. The crash is obviously trying to > write into a null pointer, but only you can find out what code is at > address 0x02f166d8. > > 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. > > -- Regards, Marc -- 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: [protobuf] Problem : Serialized in protobuf-net, deserialize in C++ app
Roey writes: [snip] > The problem is, I get a memory access violation when I try to > deserialize it :( > Unhandled exception at 0x02f166d8 in wmplayer.exe: 0xC005: Access > violation writing location 0x. > > Are any of the things I'm doing here wrong , for what I'm trying to do > (serialize in C# .NET and deserialize in C++?) Most likely yes, but it's hard to suggest what that is without a brief code example that shows the crash. The crash is obviously trying to write into a null pointer, but only you can find out what code is at address 0x02f166d8. 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.
Re: [protobuf] Problem : Serialized in protobuf-net, deserialize in C++ app
On Mar 11, 2010, at 8:39 , Roey wrote: Unhandled exception at 0x02f166d8 in wmplayer.exe: 0xC005: Access violation writing location 0x. I believe this means you are accessing a NULL pointer somewhere. You should attach a debugger to your process and look at the stack trace to figure out where this is happening. My unhelpful guess is that something is not initialized correctly. Good luck, Evan -- Evan Jones http://evanjones.ca/ -- 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: Protocol buffers performance in python
Hi, Kenton I am using Python Protobuffers library as exchange format between game client (C++ Windows application) and game server (Python socket server based on Twisted framework). After upgrade from 2.0.1 to 2.3.0 we got 4x-6x performance boost (python 2.5.2, Ubuntu 8.04) - it's great! Do you know about Petar's timeline for the new version with more power for Python code? On Jan 20, 10:45 pm, Kenton Varda wrote: > In 2.3.0, the Python implementation is now 10x-25x faster than it used to > be. However, as the implementation is pure-python, it is still much slower > than C++. Petar (author of much of the Python code) is currently working on > a version of the Python implementation which wraps the C++ library in the > hope of improving this further. > > On Wed, Jan 20, 2010 at 5:04 AM, Baruch Oxman wrote: > > > Hi ! > > > I'm interested in using Protocol buffers for serialization of data > > passed between Python and C++ processes. > > I've seen some posts on performance comparison of different python > > serializes, saying that the performance of google protocols > > implementation for python is much worse than in C++. > > > Was any work done on this recently to improve the performance on > > python ? > > Is such work planned in the future ? > > > -- > > 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] Problem : Serialized in protobuf-net, deserialize in C++ app
Hi All.
I am using ProtoBuf-Net in my .NET application to serialize the
following : (in .proto format)
message ProtoScreenBuffer {
optional int32 MediaId = 1;
optional bytes Data = 2;
optional bool LastBuffer = 3;
optional int64 StartTime = 4;
optional int64 StopTime = 5;
optional int32 Flags = 6;
optional int32 BufferSubType = 7;
optional int32 BufferType = 8;
repeated int32 EncryptedDataStart = 9;
repeated int32 EncryptedDataLength = 10;
}
I serialize this into a byte array, using protobuf-net,
and pass it to the C++ app.
What goes out of the .NET and what comes into the C++ app is 100%
identical.
It then should be deserialized in the C++ app.
I try to do :
m_screenBuffer.ParseFromArray(serBuffer, dwInputDataLen);
(where m_screenBuffer is ProtoScreenBuffer object, serBuffer is the
raw byte array I got from the .NET app, and dwInputDataLen is the
length of it.)
The problem is, I get a memory access violation when I try to
deserialize it :(
Unhandled exception at 0x02f166d8 in wmplayer.exe: 0xC005: Access
violation writing location 0x.
Are any of the things I'm doing here wrong , for what I'm trying to do
(serialize in C# .NET and deserialize in C++?)
Thanks alot.
Roey
--
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: Issue 172 in protobuf: 2.3.0 fails to compile with -Wall -Wextra -Werror
Comment #2 on issue 172 by exeonical: 2.3.0 fails to compile with -Wall -Wextra -Werror http://code.google.com/p/protobuf/issues/detail?id=172 I understand. Just thought i let you know about these errors. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings -- 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.
