how to parse a file with millions of records with protobuf

[nightwalker leo]

when I try to parse an addressbook file which has 2^20 records of
person , my program complains like this:
libprotobuf WARNING D:\protobuf-2.0.2\src\google\protobuf\io
\coded_stream.cc:459] Reading dangerously large protocol message.  If
the message turns out to be larger than 67108864 bytes, parsing will
be halted for security reasons.  To increase the limit (or to disable
these warnings), see CodedInputStream::SetTotalBytesLimit() in google/
protobuf/io/coded_stream.h.

how to deal with the problem in an elegant way instead of increasing
the limit or simply turning off the warning message?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---

Haskell protocol buffers 1.2.2 release announcement

[Chris]

Hi everyone,

To keep up with protocol-buffers 2.0.3 here is an improved Haskell 
hprotoc version 1.2.2 :

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers-descriptor
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hprotoc

These ought to be compatible with the previous version 1.2.1.

The two changes are support for the field-option-like syntax for 
EnumValueOptions, and adjacent string literals are concatenated.  Note 
that strings are checked for valid utf8 encoding after concatenation, 
not individually.  But backslash escape codes are decoded for each 
individual string, not after concatenation.  If these quirks become 
problems they can be changed.

The protoc bug fixed in 2.0.3:
   * Fixed bug where .proto files which use custom options but don't 
 actually
 define them (i.e. they import another .proto file defining the 
 options)
 had to explicitly import descriptor.proto.
did not affect hprotoc, which already did the Right Thing™ (I just 
tested to be sure).

The protoc bug fixed in 2.0.3:
   * If an input file is a Windows absolute path (e.g. 
 C:\foo\bar.proto) and
 the import path only contains . (or contains . but does not 
 contain
 the file), protoc incorrectly thought that the file was under ., 
 because
 it thought that the path was relative (since it didn't start with 
 a slash).
 This has been fixed.
is unlikely to be be present in hprotoc.  But since I never run or test 
on Windows I make no promises hprotoc is finding the correct relative 
paths on Windows.

Cheers,
  Chris Kuklewicz

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Protocol Buffers group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---