Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Chris Kuklewicz <haskell <at> list.mightyreason.com>
Subject: Announcing Haskell protocol-buffers version 1.2.2
Newsgroups: gmane.comp.lang.haskell.libraries
Date: Sunday 7th December 2008 21:17:04 UTC (over 8 years ago)
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

The darcs repository with all 3 packages is at 
http://darcs.haskell.org/packages/protocol-buffers2/

These ought to be compatible with the previous version 1.2.1.

As usual, this code read a ".proto" file which describes message formats
and 
generates Haskell modes to encode and decode corresponding data type to the

binary wire format.  Google's original protocol buffers are at 
http://code.google.com/apis/protocolbuffers/docs/overview.html
and generate code 
for C++, Python, and Java.  Other languages are listed on the wiki at 
http://code.google.com/p/protobuf/wiki/OtherLanguages
(including Haskell).

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
 
CD: 3ms