Re: setuptools version in python 2.6

This is really a bug with setuptools. It seems that they do not bother building older versions of setuptools against newer versions of Python. However, when the protobuf package was originally created, 0.6c8 was the newest version of setuptools (and Python 2.6 didn't exists yet, I suppose). As a

Re: noob link errors

What are the errors? On Tue, Apr 7, 2009 at 3:58 PM, wrote: > > I am trying to get started using pb, but I am stuck. I've got my > messages compiled into their .h and .cc parts, i've added those to my > project. I built protobuf in vs 2009, and I've added the > protobuf-2.0.3\src directory as an

Re: noob link errors

019: unresolved external symbol "public: > __thiscall google::protobuf::internal::ExtensionSet::~ExtensionSet > (void)" (??1extension...@internal@proto...@google@@q...@xz) referenced > in function __unwindfunclet$??0acti...@backupcomm@@q...@xz$0 > backupcomm error LNK2019: unresolved

Re: Protocol Buffers Vs. XML Fast Infoset

On Tue, Apr 7, 2009 at 10:15 PM, ShirishKul wrote: > I do not have any sample file to share with you. But I think FI > handles the repeatative attribute-values. OK, well, I call that "compression". Try gzipping the final protobuf and FI documents and comparing the compressed sizes. The protob

Re: Generic Object Type?

It's very likely that your problem can be better solved using extensions. http://code.google.com/apis/protocolbuffers/docs/proto.html#extensions For example, you could do: message Field { required string name = 1; optional int32 int32_value = 2; optional int64 int64_value = 3; o

Re: noob link errors

\backupcomm.pdb" /SUBSYSTEM:CONSOLE / > OPT:REF /OPT:ICF /DYNAMICBASE:NO /MACHINE:X86 /ERRORREPORT:PROMPT > ws2_32.lib wsock32.lib c:\development\libraries\lib\libprotobuf.lib > kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib > advapi32.lib shell32.lib ole32.lib oleaut32

Re: Bug in common.cc initializing log_silencer_count_mutex_

You can use "svn diff" to produce a single patch file that contains both parts of this change. On Tue, Apr 7, 2009 at 10:01 PM, Wink Saville wrote: > There is a bug in the initialization of the log_silencer_count_mutex_ in > common.cc. > Currently it is initialized because it is a global object,

Re: Bug in common.cc initializing log_silencer_count_mutex_

Although I see the decsriptor.cc part isn't meant to be submitted... On Wed, Apr 8, 2009 at 2:59 PM, Kenton Varda wrote: > You can use "svn diff" to produce a single patch file that contains both > parts of this change. > > > On Tue, Apr 7, 2009 at 10:01 PM, Wink S

Re: noob link errors

nker errors. I don't know what the problem was, but it's working > now. > > > On Apr 8, 4:10 pm, Kenton Varda wrote: > > On Wed, Apr 8, 2009 at 2:01 PM, wrote: > > > > > I don't know how else to link to libprotobuf.lib. Here's the resulting &

Re: Protocol Buffers Vs. XML Fast Infoset

On Fri, Apr 10, 2009 at 5:24 AM, Alexander Philippou < alexander.philip...@gmail.com> wrote: > The redundancy elimination mechanism of FI is actually a vocabulary > and it works differently than compression algorithms do. I think we define "compression" differently. In my book, "redundancy elim

Re: Enhancement: can we get a copy of the documentation?

Using wget (a unix command -- available on Windows using Cygwin), you can download the whole site like so: wget -r -l inf -np -p -k http://code.google.com/apis/protocolbuffers/index.html Options: -r = Recursive -l inf = Infinite recursion depth -np = Don't follow links to parent directories -p = F

Re: Enhancement: can we get a copy of the documentation?

thout asking first, it seemed kind of antisocial. :) > > > On Apr 10, 3:51 pm, Kenton Varda wrote: > > Using wget (a unix command -- available on Windows using Cygwin), you can > > download the whole site like so: > > > > wget -r -l inf -np -p -khttp:// > co

Re: Bug in common.cc initializing log_silencer_count_mutex_

g else? > > > > On Wed, Apr 8, 2009 at 2:59 PM, Kenton Varda wrote: > >> Although I see the decsriptor.cc part isn't meant to be submitted... >> >> >> On Wed, Apr 8, 2009 at 2:59 PM, Kenton Varda wrote: >> >>> You can use "svn dif

Re: Bug in common.cc initializing log_silencer_count_mutex_

like this but is non-portable, hence the different implementation in the open source release.) If you want to update your patch, go ahead, otherwise I'll take care of implementing this when it gets to the top of the queue. :) On Mon, Apr 13, 2009 at 5:21 PM, Kenton Varda wrote: >

Re: Tagged union types and "switch" statements

Thanks for doing this! Can you send it to me as a code review via codereview.appspot.com? Also, you'll need to sign the CLA if you haven't already: http://code.google.com/legal/individual-cla-v1.0.html -- If you own copyright on your work. http://code.google.com/legal/corporate-cla-v1.0.html -- I

Re: Bug in common.cc initializing log_silencer_count_mutex_

so this would make protobuf more amenable to embedded systems > where reloads my not occur and an explicit initialization call would be > needed. > > I'd be glad to do a first pass at coding this if people would be > interested. > > -- Wink > > > On Mon, Apr 13, 2009 at

Re: Printing out unset fields

The descriptor itself contains a list of all of the defined fields for the type. E.g.: const Descriptor* type = message->GetDescriptor(); for (int i = 0; i < type->field_count(); i++) { const FieldDescriptor* field = type->field(i); // handle field } On Tue, Apr 14, 2009 at 6:09 PM,

Re: Bug in common.cc initializing log_silencer_count_mutex_

good idea. > I'm still in favor of an explicit initialization as a long term solution > where > all ordering issues are controlled. Your thoughts on this? To me it sounds like a lot of work without very much benefit. > > > > On Tue, Apr 14, 2009 at 10:29 AM, Kenton Va

Re: Backwards Compatibility of sizes and encodings.

We will absolutely maintain backwards-compatability of the wire format in future versions. A version of protocol buffers that wasn't backwards compatible would be thoroughly useless. However, our idea of "compatibility" means that newer versions of the code can successfully parse messages produced

Re: Backwards Compatibility of sizes and encodings.

code to the libraries for reading/writing "delimited" messages, which would encode their size as a varint before the message data itself, but this would probably only be used by non-Google users. Until then you might be best-off writing your sizes just as simple fixed-width values, using y

Re: Bug in common.cc initializing log_silencer_count_mutex_

ere first, great. >> >> As for the explicit initialization I humbly disagree but I understand >> your point completely. Maybe someday there will be another >> initialization issue that isn't as easily solved and it can be revisited. >> >> -- Wink >> &

Re: PATCH: Optimized version of OutputStream

Petar, can you review this? Christian: Thanks, I don't think we had any idea this was happening (doh). Can you sign the CLA if you haven't already? http://code.google.com/legal/individual-cla-v1.0.html -- If you own the copyright on your patch. http://code.google.com/legal/corporate-cla-v1.0.htm

Re: Is there a need or desire for protobuf-lite?

On Mon, Apr 20, 2009 at 8:51 PM, Wink Saville wrote: > I assume the wire format for all variations of protobuf > are compatible of course there are no guarantees. Yes, they are definitely compatible. > > > In my little test program I'm using both and see that > they are generating the same da

Re: Is there a need or desire for protobuf-lite?

The protocol buffers implementation was designed to run on beefy server machines where we regularly run binaries with hundreds of megs of code and don't worry about it that much. Optimizing for code size does make the code a lot slower, true, but this is compared to an insanely fast base. It's lik

Re: FindMessageTypeByName in java

There is no central repository of descriptors in Java. It wouldn't really work because Java normally does not load classes until they are first used, so the descriptors wouldn't appear in the repository until you manually loaded the classes somehow. Instead, you should just create a Map and popula

Re: more options to validate field values

This is suggested from time to time. The problem is that validating messages is an arbitrarily complex operation, and the only "complete" solution to this problem would involve defining an entire turing-complete functional programming language which you could use to specify validation constraints.

Re: Serialization "exceptions"

SerializeTo*() only aborts if required fields are missing. You can protect yourself against this problem in any of the following ways: * Compile your release builds with NDEBUG defined. The check will then be skipped in release builds, and the message will be written even if some required fields

Re: Serialization "exceptions"

lt; eda...@gmail.com> wrote: > Thanks for the reply - that helps. > I guess if the NDEBUG route is recommended, we'll probably go with that. > But just for the record - are all the cases which can cause abort() > documented somewhere? > Thanks, > --edan > > > On Tu

Re: Make error on FreeBSD after link

It appears as if your make is not properly expanding the $^ variable -- it's replacing it with the empty string. Try using gmake? On Thu, Apr 23, 2009 at 8:22 AM, wrote: > > Hi, > > I am trying to build protobuf 2.0.3 on FreeBSD 7.1 and am running into > an error in the make immediately after t

Re: Immutability of generated data structures

You're specifically talking about the Java implementation. We quite intentionally chose to make message objects completely immutable. Version 1 of protocol buffers (never released publicly) used mutable objects, and we found it lead to many bugs as people would modify messages that were simultane

Re: Immutability of generated data structures

detect cycles in your serialization algorithm, I'm guessing you aren't interested in detecting when the same object appears in multiple places. So your serialization is really writing trees anyway. > > > - Kannan > > On Thu, Apr 23, 2009 at 15:21, Kenton Varda wrote: >

Lots of changes integrated, 2.1.0 release coming soon

Hi all, I just updated SVN (rev 120) with a large bundle of changes recently made to our internal copy of the code. The easiest way to see what's new is to look at the diff of CHANGES.txt: http://code.google.com/p/protobuf/source/diff?spec=svn120&r=120&format=side&path=/trunk/CHANGES.txt Most of

Re: Lots of changes integrated, 2.1.0 release coming soon

ke environments. Do you know how big the performance penalty > is for using array-based InputStream in protobuf context? > > Thanks, > > Yegor > > On Apr 24, 9:01 pm, Kenton Varda wrote: > > Hi all, > > I just updated SVN (rev 120) with a large bundle of changes re

Re: More Dynamic Python Accessors?

On Mon, Apr 27, 2009 at 8:38 PM, Dan wrote: > > Hello, > I've recently started using Google Protocol Buffers with Python on my > server. I'm writing code to convert my data source into a binary > payload, but I'm running into some snags and was wondering if there > was a better way I'm not seein

Re: More Dynamic Python Accessors?

my first > readthrough and was using MergeFrom, which I would guess is a tad > slower.) > > -Daniel > > On Tue, Apr 28, 2009 at 12:58 AM, Kenton Varda wrote: > > > > > > On Mon, Apr 27, 2009 at 8:38 PM, Dan wrote: > >> > >> Hello, > >&g

Re: Python Installation without superuser

We use setuptools to manage installations. If there's a way to do this, it should be documented in the setuptools documentation. http://peak.telecommunity.com/DevCenter/setuptools I suspect it's there somewhere but haven't tried it myself. You could also just run "setup.py test" and then copy th

Re: protobuf for embedded system

Currently the C++ implementation is not very well designed for embedded systems -- it was designed for beefy servers. We're looking into fixing that, but in the meantime you might want to use protobuf-c. http://code.google.com/p/protobuf-c/ If you really want to use the C++ implementation, you c

Re: Thoughts on a cleaner Java protocol buffer compiler.

On Wed, Apr 29, 2009 at 1:14 PM, burtonator wrote: > > I have a few thoughts after looking at the generated Java source. > > No particular order... > > - why does the class have to be final? I can see one wanting to have > business logic (or data type manipulation logic) that protobufs don't > pr

Re: Question about building a message

You can simplify your code to: bBuilder.setSomeA(A.newBuilder(bBuilder.getSomeA()).setStr(s)); If someA is not already present in bBuilder, getSomeA() will return the default instance, and A.newBuilder() is smart enough to know that it doesn't need to copy the default instance. You could also

Re: Services method invocation (server side) question

The incoming request has to somehow specify what method it is trying to call. Then you can do: const MethodDescriptor* method = service->GetDescriptor()->FindMethodByName(method_name); if (method == NULL) { // no such method } else { Message* request = service->GetRequestPrototyp

Re: Arbitrary fields/attributes fail to save properly (or load properly?)

Can you write a small example program demonstrating your problem? I can then debug it. On Sun, May 3, 2009 at 8:33 AM, wrote: > PS. is there a reason the compiler turns camelCaseFields into > noncamelcasefields, but messageNamesAreStillPreservedWithCamelCase? Historical reasons. In the early

Re: Read/Write RepeatedField Ondemand

Unfortunately these kinds of problems are considered outside the scope of what the Protocol Buffers library provides. You will need to devise some sort of container format which implements the features you want. You can still use protobufs to encode individual messages, and then have your contain

Re: Arbitrary fields/attributes fail to save properly (or load properly?)

BTW, another user recently had a problem where using field number 3 seemed to cause serialization or parsing to fail. It turned out he was using Windows and forgot to set the "binary" flag when he opened his file, so the stream was doing newline conversion. On Sun, May 3, 2009 at 8:33 AM, wrote:

Re: Using Protocol Buffers in a MSVC++ 2008 DLL

Are you, like Fedor, linking to the CRT statically (/MT)? If so, does linking dynamically (/MD) change anything? I wonder if this leads to a condition where CRT functionality is being used before it has been initialized -- because initialization order between the CRT and libprotobuf would not be

Re: Using Protocol Buffers in a MSVC++ 2008 DLL

lease this week. On Mon, May 4, 2009 at 9:45 AM, Peter K. wrote: > > Hi Kenton, > > Thanks for the quick response. > > On May 4, 12:07 pm, Kenton Varda wrote: > > > Are you, like Fedor, linking to the CRT statically (/MT)? If so, does > > linking dynamicall

Re: Using Protocol Buffers in a MSVC++ 2008 DLL

On Mon, May 4, 2009 at 11:12 AM, Peter K. wrote: > OK, there seems to be projects called "gtest" and "gtest_main" that > are in the solution file, but don't seem to be in the repo. Oh yeah, you're expected to run autogen.sh to get that, but I guess that's hard on Windows unless you have Cygwin.

Re: Using Protocol Buffers in a MSVC++ 2008 DLL

autogen.sh). Anyway, point is you don't need cygwin unless you want to build the protobuf tests from SVN. On Mon, May 4, 2009 at 5:46 PM, Peter K. wrote: > > > > On May 4, 7:57 pm, Kenton Varda wrote: > > On Mon, May 4, 2009 at 11:12 AM, Peter K. wrote: > > &g

Re: Implement ShutdownProtobufLibrary().

On Tue, May 5, 2009 at 8:15 PM, Hong Zhang wrote: > Hi, Kenton, > > I am not familiar with protobuf compiler, so my comment may be off. > > Since existing code does something like this. > > static class Foo { > Foo() { ... } > } foo; Actually, a lot of code doesn't look like that anymore, beca

Re: Protocol Buffers RPC Server Implemention based on Mina(2.0-M5) and Protobuf(2.0.3)

Added to http://code.google.com/p/protobuf/wiki/RPCImplementations On Tue, May 5, 2009 at 10:26 PM, Jun Tsai wrote: > > Protocol Buffers RPC Server Implemention based on Mina(2.0-M5) and > Protobuf(2.0.3). > I had implemented a protocol buffers rpc server. > > http://github.com/bitiboy/fepss-rpc

Re: Implement ShutdownProtobufLibrary().

Thanks, committed as revision 138. On Wed, May 6, 2009 at 12:26 PM, wrote: > Looks good! > > > On 2009/05/06 19:05:36, kenton wrote: > >> Addressed comments (see below) and synced, new patch set uploaded. >> > > http://codereview.appspot.com/53053/diff/1/5 >> File google/protobuf/compiler/cpp/c

2.1.0 release candidate

Hi all, I've uploaded release candidate 2.1.0rc1 here: http://groups.google.com/group/protobuf/files?pli=1 If you get a chance, test it out, and report back on what platform you use and whether or not it worked. (Monty, I'm particularly interested in your results, since you seem to be a heavy us

Re: Odd errors related to package and field names

Write the field like this: optional .foo.Foo foo = 1; The leading period tells the compiler that "foo" refers to the foo at the global scope (i.e. the package), not the foo in the current scope (the field). (It's the same semantics and C++ namespaces.) This is also fixed in version 2.1.0 -- ty

Re: 2.1.0 release candidate

be flipped from "multi-threaded" to "multi-threaded DLL", otherwise the linker gets upset. I forgot to do this after my last update of the gtest code. On Wed, May 6, 2009 at 2:34 PM, Kenton Varda wrote: > Hi all, > I've uploaded release candidate 2.1.0rc1 her

Re: 2.1.0 release candidate

On Fri, May 8, 2009 at 7:08 AM, Peter K. wrote: > 1. MS Dev Studio 2008 converts the project on opening the solution > file. Yep, that's expected -- we distribute MSVC 2005 project files (and gtest's are MSVC 2003). > > 2. cl : Command line warning D9035 : option 'Wp64' has been deprecated >

Re: More MSVC2008 Woes

What does your protoc command-line look like? Does your project contain multiple .proto files that import each other? If so you need to make sure to pass the same -I (or --proto_path) flag to each one. On Fri, May 8, 2009 at 5:47 AM, Peter K. wrote: > > Hi All, > > OK, so we've compiled the DL

Re: Bit fields in protocol buffer

On Fri, May 8, 2009 at 9:03 AM, Henner Zeller wrote: > fixed32 or fixed64 would be probably better. uint32 is encoded in > variable length which would make bitfields typically larger than > necessary. Depends. If you are only using the first few (low-order) bits, then uint32 is probably better

Re: Compiling Protocol Buffer (64) using gcc in Sun 9 (libgcc_s.so: wrong ELF class: ELFCLASS32)

Can you provide a patch with your exact changes? Maybe we could integrate them into the mainline. On Fri, May 8, 2009 at 12:13 PM, acidfilez wrote: > > I needed to compile pb in 64, here it goes: > > My Plataform > > Using Solaris 9. spark, gcc (3.4.6) > > I compile using this configure. > > >

Re: Bit fields in protocol buffer

On Fri, May 8, 2009 at 2:27 PM, Henner Zeller wrote: > > On Fri, May 8, 2009 at 2:06 PM, Kenton Varda wrote: > > > > > > On Fri, May 8, 2009 at 9:03 AM, Henner Zeller wrote: > >> > >> fixed32 or fixed64 would be probably better. uint32 is encode

Re: 2.1.0 release candidate

The "packed" encoding would not provide much benefit for strings, groups, or messages, so we did not implement it for those. You can still have regular "repeated" fields of these types, just not packed ones. There's no theoretical reason why we couldn't implement packed repeated strings, groups,

Re: More MSVC2008 Woes

8, 2009 at 6:41 PM, Peter K. wrote: > > > On May 8, 5:04 pm, Kenton Varda wrote: > > > What does your protoc command-line look like? Does your project contain > > multiple .proto files that import each other? If so you need to make > sure > > to pass the

Re: Protocol Buffers RPC Server Implemention based on Mina(2.0-M5) and Protobuf(2.0.3)

On Fri, May 8, 2009 at 9:49 PM, wrote: > It was necessary to add a length prefix to the request/response > messages in order to remove the dependency on closing the connection > to know when the protobuf was finished being read. Also, since > Message.Builder.mergeFrom() expects to be able to read

Re: Writing Python unit test cases for Protocol Buffers

What do you mean? It seems to me that they should be written the same way you'd write any other unit test in Python. On Mon, May 11, 2009 at 3:51 AM, wrote: > > Hi, > > Can anyone tell me how to proceed with writing Python Unit test cases > for Protocol Buffers. It would be great if someone can

Re: ctype implementation plans for messages?

All ctype does is allow you to use a couple of non-standard string implementations which are often used in our codebase. In some cases they can improve performance, but they are very rarely used. Cord is the more useful representation but it also has a lot of dependencies on other, unrelated Goog

Re: string vs. bytes

Protocol Buffers has a "bytes" type. That's what it's talking about. Just change "string" to "bytes" in your .proto file. (They work exactly the same in C++ but are different in Java and Python.) On Tue, May 12, 2009 at 6:47 AM, wrote: > > I am having a very similar problem. Just installed the

Re: string vs. bytes

case for using serialisation to a > stream then? > > Thanks again for the help. > > Dan > > On May 12, 5:26 pm, Kenton Varda wrote: > > Protocol Buffers has a "bytes" type. That's what it's talking about. > Just > > change "string" to

Re: Cross Compiling Protobuf

In v2.1.0 I've added a parameter to the configure script --with-protoc= which lets you specify an alternate protoc binary to use when compiling. This way, the makefiles won't invoke the protoc they just built. So, cross-compiling should work. However, I haven't actually tested this with cross-com

Re: Class hierarchy serialization

On Tue, May 12, 2009 at 12:28 PM, Marc Gravell wrote: > > What implementation are you using? Given that most of the > implementations use code-generation (rather than reflection), I'm > wondering if this is protobuf-net? > (since that supports inheritance by representing it as nested > messages).

Re: How to iterate over repeated fields from metadata

Yes, use descriptors and the reflection interface. What language are you using? On Tue, May 12, 2009 at 1:31 PM, ajoy wrote: > > I'm trying to write a recursive function that goes thru all fields of > a message. Without hardcoding anything, is there a way to retrieve all > repeated fields of a

Re: How to iterate over repeated fields from metadata

On Tue, May 12, 2009 at 2:34 PM, ajoy wrote: > > Thanks! > I'm using C++ > got around mainly with the help of reflection->FieldSize(*message, > field) and reflection->GetRepeatedMessage(*message, field, j); That's the way to do it. > > > > On Ma

2.1.0 release is up

http://code.google.com/p/protobuf/downloads/list Aaaand, I just realized that CHANGES.txt still has the release date as . :( /me is not very good at release engineering. Oh well. --~--~-~--~~~---~--~~ You received this message because you are subscribed to th

Re: 2.1.0 release is up

Here's the major changes (from CHANGES.txt): General * Repeated fields of primitive types (types other that string, group, and nested messages) may now use the option [packed = true] to get a more efficient encoding. In the new encoding, the entire list is written as a single byte

Re: 2.1.0 release is up

Updated documentation covering all this has been submitted and should go live in a couple hours. http://code.google.com/apis/protocolbuffers/docs/overview.html On Wed, May 13, 2009 at 4:06 PM, Kenton Varda wrote: > Here's the major changes (from CHANGES.txt): > General > * R

Re: 2.1.0 release is up

Yep, it's there in Java. I didn't get the chance to add the equivalent support to C++ or Python yet, but if someone wants to submit a patch, go for it. On Thu, May 14, 2009 at 7:27 AM, Antony Dovgal wrote: > > On 14.05.2009 18:18, clint.foster wrote: > > It's very nice to see support in the API

Re: pthread now required?

Yes, linking against pthreads is required. Technically it always was, but on certain platforms (e.g. Linux), it just happened that the set of pthread functions used by libprotobuf were all implemented in libc itself, so if you forgot to use -lpthead it worked anyway. I suppose that should be in th

Re: Memory leaks on VS2008/C++

FYI: This is fixed in the 2.1.0 release (you can call google::protobuf::ShutdownProtobufLibrary() to clean up all "leaks"). On Fri, Mar 27, 2009 at 7:07 PM, Kenton Varda wrote: > On Fri, Mar 27, 2009 at 4:30 PM, Oleg Smolsky wrote: > >> So, the next question is - woul

Re: Cross-compile of Google Protocol Buffers fails

FYI: This is fixed in the 2.1.0 release. Use the --with-protoc option to configure to tell it to use a pre-compiled protoc executable during the build process, instead of using the one it just built. This should allow cross-compiling. On Mon, Feb 2, 2009 at 5:54 PM, Kenton Varda wrote

Re: 2.0.3 officially released

On Mon, Jan 5, 2009 at 12:45 PM, Kenton Varda wrote: > On Sat, Jan 3, 2009 at 7:32 PM, Dave Wolfe wrote: > >> >> FYI, it looks like a few new functions are missing __declspec() >> decorators. I had to apply the trivial patch below in order to >> build a DLL ver

Re: Enum for field numbers

This was implemented for 2.1.0. Check the generated code docs for your language, under "fields", to see what the new constants look like. On Tue, Dec 16, 2008 at 12:44 PM, Kenton Varda wrote: > Hmm, I think a better idea would be for the protocol compiler to generate > an enum

Re: TextFormat::PrintFieldValueToString adds double quotes to string fields?

What's wrong with switching on cpp_type? PrintFieldValueToString() prints the value as it would appear in text format, where quotes (and escapes) are definitely required. If that's not the logic you want, you need to implement your own thing. On Thu, May 14, 2009 at 2:09 PM, ajoy wrote: > > Is

Re: Memory leaks on VS2008/C++

0 FF FF FF FF 00 00 00 00 00 00 00 00 > {135} normal block at 0x00245238, 24 bytes long. > Data: < s( > C8 73 28 00 FF FF FF FF 00 00 00 00 00 00 00 00 > Object dump complete. > > > On 2009/5/14 13:08, Kenton Varda wrote: > > FYI: This is fixed in the 2

Re: Cross-compile of Google Protocol Buffers fails

On Thu, May 14, 2009 at 4:08 PM, wrote: > There's only one problem with this. It assumes that you have a locally > compiled and installed the protoc compiler. Thus, before building a > cross-compiled version, one must also build a native version. This is an > unnecessary dependency that shoul

Re: Memory leaks on VS2008/C++

Ugh, I missed that one because I was doing my testing on Linux and that is in Windows-only code. Ideally I'd prefer if each GoogleOnce object registered a shutdown function for itself. But I suppose that could create a deadlock because the shutdown function registry is once-initialized. So, sure,

Re: Cross-compile of Google Protocol Buffers fails

On Fri, May 15, 2009 at 5:06 PM, wrote: > Kenton, > > > > The flaw in your assumption is that I actually use the current machine to > build my product. I don't. > > > > I'm cross-compiling on platform A (redhat) for deployment on platform B > (mips). Other than the cross-compilation, I never,

Re: 2.1.0 release is up

On Sun, May 17, 2009 at 6:57 AM, Chris Kuklewicz wrote: > > I am patching the Haskell implementation and I have a follow up > question to this: > > On May 14, 12:06 am, Kenton Varda wrote: > > * The type name resolver will no longer resolve type names to fields. > F

Re: Memory leaks on VS2008/C++

Committed as rev 146. On Fri, May 15, 2009 at 7:23 PM, Oleg Smolsky wrote: > Here we go. > > > On 2009/5/15 18:56, Kenton Varda wrote: > > Ugh, I missed that one because I was doing my testing on Linux and that is > in Windows-only code. > Ideally I'd pre

Re: using namespace std

I cannot reproduce this problem in MSVC 2008. Are you using precompiled headers? Could it relate to that? What happens if you replace "using namespace std;" with a bunch of "usign std::Foo;" lines covering everything used by libprotobuf? On Mon, May 18, 2009 at 11:34 AM, Zachary Turner wrote: >

Re: Python C Implementation - Update Request

Any comment, Petar? On Fri, May 15, 2009 at 7:21 AM, Nicholas Reid wrote: > > Hi Petar & Kenton, > > Have there been any recent developments on the Python C > implementation? I'd be more than happy to run a prototype through its > paces for testing purposes and provide feedback - it would be gre

Re: Protocol buffers and EBCDIC

If your compiler transforms string literals to a non-ASCII character set, then the code generated by the protocol compiler won't work. We could perhaps fix this by escaping every character in the embedded descriptor, but other problems might come up. I don't have enough experience with EBCDIC to

Re: Can't this project can be listed on http://code.google.com/p/protobuf/wiki/RPCImplementations.

You sent me a personal e-mail to which I replied. My reply was that I unfortunately don't have time to review any large amount of code, but I'm happy to put this on the list anyway if you'd like. On Mon, May 18, 2009 at 7:36 PM, xiliu.t...@gmail.com wrote: > Any update on this, kenton? > --Xiliu

Re: using namespace std

The code does not compile in VS2k8. Did you try replacing the "using namespace std;" with a bunch of individual "using std::Foo;" directives? Can we work around the problem that way? On Mon, May 18, 2009 at 11:56 AM, Zachary Turner wrote: > > I managed to get it down to a minimal sample that rep

Re: using namespace std

st = "hello"; >return 0; > } > > > fails to compile in Vs2k5 which is the correct behavior, so I guess that's > a valid workaround. > > On Tue, May 19, 2009 at 4:26 PM, Kenton Varda wrote: > >> The code does not compile in VS2k8. >> Did

Re: Compiling protocol buffers 2.0.3 with sun studio 11

On Wed, May 20, 2009 at 12:35 AM, wrote: > "./google/protobuf/stubs/once.h", line 114: Warning (Anachronism): > Formal argument 2 of type extern "C" void(*)() in call to pthread_once > (_once*, extern "C" void(*)()) is being passed void(*)(). This warning seems to be saying that pointers to fun

Re: Protocol buffers and EBCDIC

ternative to XML, which is proving to be a huge bottleneck for mainframe >> applications trying to web enable legacy applications. >> >> What modules/classes contain the ASCII specific code? >> >> > ok, it looks like the problem is tokenizer.cc - the character classes ai

Re: Cross-compile of Google Protocol Buffers fails

any model which involves skipping tests when there's a reasonable chance they may not pass is not a good model to follow, and would never fly at Google. > > > IMO, you should provide a --cross-compile option so the build knows when to > not run tests… Or, better yet, use the auto-to

Re: Compiling protocol buffers 2.0.3 with sun studio 11

On Wed, May 20, 2009 at 10:44 AM, Monty Taylor wrote: > Kenton Varda wrote: > > > > > > On Wed, May 20, 2009 at 12:35 AM, > <mailto:cosmin.cremare...@gmail.com>> wrote: > > > > "./google/protobuf/stubs/once.h", line 114: Warning (An

Re: Maven Artifacts?

Greg, can you push 2.1.0 to the maven repo? On Thu, May 21, 2009 at 6:18 AM, huxi wrote: > > Hi everyone, > > The current 2.1.0 release hasn't reached the CMR (central maven > repository), yet. > > > http://mirrors.ibiblio.org/pub/mirrors/maven2/com/google/protobuf/protobuf-java/ > > Any idea wh

Re: Compiling protocol buffers 2.0.3 with sun studio 11

On Wed, May 20, 2009 at 12:58 PM, Monty Taylor wrote: > Works fine then, as I'm using it pretty consistently with Sun Studio - > guess it's just the pedanticness. Note that the whole "once" thing is new in 2.1.0 -- you've tested that one, right? --~--~-~--~~~---~--~

Re: Python socket implementation

Done. On Wed, May 20, 2009 at 10:41 AM, Martin wrote: > > Hi, > > I've recently uploaded a Python version of Shardul Deo's Java socket > implementation of the Goolge Protocol Buffers. Can you update the link > to the following:- > > http://code.google.com/p/protobuf-socket-rpc/ > > to show that

Re: New Protocol Buffer implementation, Java ME support

I've added this to the "other languages" wiki. http://code.google.com/p/protobuf/wiki/OtherLanguages On Wed, May 20, 2009 at 11:22 AM, wrote: > > Hi everyone, > > I have just released my project for adding Protocol Buffer support for > Java ME. The project site is: http://code.google.com/p/proto

Re: libprotobuf ERROR google/protobuf/message.cc:121

You can capture log output using SetLogHandler(): http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.common.html#SetLogHandler.details However, you have a d

<    1   2   3   4   5   6   7   8   9   10   >