Yes, that does seem odd, but it's the only thing that came to mind. I
haven't seen this crash before. It might help if you had line numbers.
On Wed, Oct 21, 2009 at 11:06 PM, edan wrote:
> I can try that - I actually thought exit() was safe to call from a signal
> handler - thanks for opening
Hi,
I am having some troubles with protocol buffers 2.2.0 together with
the windows headers. I receive the following linker error:
error LNK2019: unresolved external symbol "public: class
google::protobuf::MessageLite const & __thiscall
google::protobuf::internal::ExtensionSet::GetMessageW(int,c
Do you still need me to upload the zip file to
codereview.appspot.com? The link http://www.codeshed.co.nz/protocolbuffers.php
is permanent so maybe you could update the wiki so that fellow Borland/
Codegear/Embarcadero (whatever it is called these days) C++ Builder
users can discover this and giv
I've been wasting my time doing various microbenchmarks when I should
be doing "real" work. This message describes some "failed" attempted
optimizations, ideally so others don't waste their time.
I was looking at the Java CodedOutputStream implementation, and was
interested that it uses an
Hi Kenton,
-pthread : did work
-lpthread : did not work - although I don't understand why
Thanks for the pointer to GTEST_HAS_DEATH_TEST - I was able to run the full
tests and sadly they all didn't pass. Here are the results - you think it's
safe to use on the blackfin? The other tests passed
(
I have a fix for GzipInputStream, but the test for it is revealing
that on a couple output buffer sizes, GzipOutputStream appears to be
producing irregular output and I haven't fixed that yet.
On Mon, Oct 19, 2009 at 7:35 PM, Brian Olson wrote:
> I have something coded in zero_copy_stream_unitte
It would be nicer to get the changes into the official release if possible,
rather than have a fork which may become out-of-date. But for that, I
really need you to provide a patch, preferably against the latest SVN
sources, rather than a zip file that doesn't even have matching file names.
I wil
There's a hack at the top of message.h to deal with this. I suppose it
should have been moved to message_lite.h when lite mode was introduced.
On Thu, Oct 22, 2009 at 2:41 AM, villintehaspam wrote:
>
> Hi,
>
> I am having some troubles with protocol buffers 2.2.0 together with
> the windows head
Hey, it's great that you're trying things. I think there's room for
improvement in the Java implementation (as opposed to C++), and it tends to
take some trial-and-error.
You note that small messages seem faster with smaller buffer sizes, but
larger messages are slower. I am guessing that by "sma
The TextFormat failures suggest that either your printf() or your strtod()
implementation is poor, but can probably be ignored if you don't care about
TextFormat printing floating points nicely.
The "couldn't parse default value" errors suggest that your system is having
problems printing negative
This is an extract on how I append new output:
fileDescriptor = ::open(fileName.c_str(), O_RDWR);
std::auto_ptr fileInStream(new
google::protobuf::io::FileInputStream(fileDescriptor));
::lseek64(fileDescriptor, 0, SEEK_END);
fileOutStream.reset(new google::protobuf::io::FileOutputStream(fileDescr
On Oct 22, 2009, at 16:36 , Kenton Varda wrote:
> You note that small messages seem faster with smaller buffer sizes,
> but larger messages are slower. I am guessing that by "small
> messages" you mean ones which are significantly smaller than the
> buffer size, and "large messages" means l
12 matches
Mail list logo
