On Mar 5, 11:39 pm, Kenton Varda ken...@google.com wrote:
As you know if you've read the docs carefully, when using C++ or Java
protocol buffers, for best performance you need to add a line to your .proto
files:
option optimize_for = SPEED;
snip commentary
I think there are three issues
Oops. Forgot to include the list in the response...
-- Forwarded message --
From: Monty Taylor monty.tay...@gmail.com
Date: Fri, Mar 6, 2009 at 1:01 AM
Subject: Re: Protocol Buffer compiling on Sun Sparc 64 bit.
To: Marakan rad...@gmail.com
gcc on Sun is really old (3.4) ... I
On Mar 6, 1:13 am, Justin Azoff justin.az...@gmail.com wrote:
I did a quick port to python(pasted at the end, hopefully it wont be
garbled)
well, that didn't work.
I threw it up at http://bouncybouncy.net/ramblings/files/ProtoBench.py
if anyone is interested.
--
- Justin
On Mar 6, 1:24 pm, Justin Azoff justin.az...@gmail.com wrote:
On Mar 6, 1:13 am, Justin Azoff justin.az...@gmail.com wrote: I did a
quick port to python(pasted at the end, hopefully it wont be
garbled)
well, that didn't work.
I threw it up
Isn't this a common scenario in C++ for which stdlib provides a simple
solution, std::auto_ptr? std::auto_ptr is a lightweight class designed
to RAIIify pointers. What am I missing?
On Mar 4, 3:06 pm, Kenton Varda ken...@google.com wrote:
http://code.google.com/p/protobuf/issues/detail?id=54
+1 for making it a compiler command-line option.
Pretty much all other IDLs get this wrong to some degree also.
Having annotations or options in the IDL file is nice, but make sure
they are only helping to define the message and the service, not the
implementation.
When I get a service
+1 for making it a compiler command-line option.
Pretty much all other IDLs get this wrong to some degree also.
Having annotations or options in the IDL file is nice, but make sure
they are only helping to define the message and the service, not the
implementation.
When I get a service
On Mar 6, 2:23 pm, aepensky apen...@gmail.com wrote:
+1 for making it a compiler command-line option.
Pretty much all other IDLs get this wrong to some degree also.
Having annotations or options in the IDL file is nice, but make sure
they are only helping to define the message and the
Sorry, I realize that wasn't a very clear statement...
What I mean is, if there is an option which does not leave any
fingerprint in either the serialized message or the
FileDescriptorSet, so that you can't tell how the option was set by
looking at either of these, then the option is controlling
On Mar 6, 4:55 pm, aepensky apen...@gmail.com wrote:
Sorry, I realize that wasn't a very clear statement...
What I mean is, if there is an option which does not leave any
fingerprint in either the serialized message or the
FileDescriptorSet, so that you can't tell how the option was set by
I agree that there should be a way to specify options on the command-line.
This applies to pretty much *all* options -- optimize_for, java_Package,
ctype, etc. It would even be useful to be able to munge package and class
names on the command-line, so that you can generate the same .proto file
On Fri, Mar 6, 2009 at 5:50 AM, marc vaill...@cis.jhu.edu wrote:
Isn't this a common scenario in C++ for which stdlib provides a simple
solution, std::auto_ptr? std::auto_ptr is a lightweight class designed
to RAIIify pointers. What am I missing?
Deleting the objects on shutdown is easy.
On Fri, Mar 6, 2009 at 1:41 AM, anthonyp anthony.p...@pri.com.au wrote:
When receiving an encoded protocol buffer message containing
extensions it does not appear to parse correctly when using
ParseFromArray(const void * data, int size) in C++
Can you describe what you mean by does not
The only reason you aren't seeing a problem with that code is because it
exits very quickly after ~B() is called, before the other thread gets a
chance to be scheduled again. In a large program, shutdown might not be so
fast. Try putting a sleep(1) at the end of B::~B() -- you'll see that the
Hi everyone,
I have a python app that passes objects using protocol buffers. This
app *depends* on the ability to pass strings as strings and not as
Unicode objects - data ends up being distributed to routers and
switches via SNMP where Unicode causes tons of problems.
Prior to 2.0.3, when I
You need to use the bytes type instead of string. string has always
been defined in the docs as UTF-8, it just wasn't enforced in the Python
implementation.
On Fri, Mar 6, 2009 at 12:40 PM, Ross Vandegrift r...@kallisti.us wrote:
Hi everyone,
I have a python app that passes objects using
How hard would it be to modify the code generator so that whenever there was
a field of type bytes, a method was generated called
assign_allocated(const char*, int nSize), that instead of creating an
std::string(), would just store the raw pointer as well as the size, and not
take ownership of the
This is pretty much what the ctype=STRING_PIECE option does... but it
wasn't included in the public release, since it required some extra classes
and we find we rarely use it internally. I've been meaning to port it at
some point but haven't had time... I'll bump it up my todo list.
On Fri,
Protorpc has moved to http://protorpc.lekebilen.com I'll upload the
repositories for the different ports to github etc. to use a more
stable server. I have also ported it to Qt/c++ (now it supports Java,
Python (buggy) and Qt/C++). It would be good if the link in the wiki
is updated.
Hmm, that's the same link I already had for you. I updated the wiki to list
the languages you support.
On Fri, Mar 6, 2009 at 1:26 PM, freq...@gmail.com wrote:
Protorpc has moved to http://protorpc.lekebilen.com I'll upload the
repositories for the different ports to github etc. to use a
On Fri, Mar 06, 2009 at 12:58:08PM -0800, Kenton Varda wrote:
You need to use the bytes type instead of string. string has always
been defined in the docs as UTF-8, it just wasn't enforced in the Python
implementation.
Aha, that did it. Switching to bytes and I get strings out.
Thanks for
Sorry, fixed.
On Fri, Mar 6, 2009 at 1:53 PM, freq...@gmail.com wrote:
On 6 Mar, 22:32, Kenton Varda ken...@google.com wrote:
Hmm, that's the same link I already had for you. I updated the wiki to
list
the languages you support.
note lekebilen!=likbilen (and please check that the link
Almost :-)
I was looking to do the same thing - thanks for the helping hand with
the script.
I tried yours - failed, the command 'lipo -info libname' said I had
created an i386 library. Ah I thought to meself...
So here's my build script, derived from yours:
- beginning
Ok, thanks. There are other problems though. If A::b was a B* instead
of a std::auto_ptrB, then the data that A::b points to will be ok
because it won't be deleted. However, A::b would get deleted so access
to the data via A::b may be undefined.
Also I found that static vars local to the
On Fri, Mar 6, 2009 at 6:41 PM, Marc Vaillant m...@jhu.edu wrote:
Ok, thanks. There are other problems though. If A::b was a B* instead
of a std::auto_ptrB, then the data that A::b points to will be ok
because it won't be deleted. However, A::b would get deleted so access
to the data via
25 matches
Mail list logo
