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.
> For
> > example, this now works:
> > message Foo {}
> > message Bar {
> > optional int32 Foo = 1;
> > optional Foo baz = 2;
> > }
> > Previously, the type of "baz" would resolve to "Bar.Foo", and you'd
> get
> > an error because Bar.Foo is a field, not a type. Now the type of
> "baz"
> > resolves to the message type Foo. This change is unlikely to make a
> > difference to anyone who follows the Protocol Buffers style guide.
>
> You did not fix this similar case, where the "int32 Baz" field causes
> an error when trying to extend the "message Baz":
>
> package test_resolve;
>
> message Foo {
> optional int32 Baz = 2;
>
> extend Baz {
> optional int32 nonsense = 76335;
> }
> }
>
> message Baz {
> extensions 100 to max;
> }
>
> I will make the Haskell version compatible with protoc-2.1.0 but
> perhaps you want to make the above a legal proto file in the future.
>
> What do people think?
You're right, this should have been handled too. Oh well, I'll stick it on
my TODO list for a later release.
Hopefully most open source users follow the style guide, making this
irrelevant. Inside Google we unfortunately have a lot of code that predates
the style guide and uses CamelCase field names. People kept getting
confused as to why code like this didn't work:
optional Foo Foo = 1;
even though similar code also would not work in any of our main programming
languages (C++, Java, Python). Eventually I caved and made it a non-error
so that people would stop complaining.
--~--~-~--~~~---~--~~
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
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
Re: 2.1.0 release is up
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. For
> example, this now works:
> message Foo {}
> message Bar {
> optional int32 Foo = 1;
> optional Foo baz = 2;
> }
> Previously, the type of "baz" would resolve to "Bar.Foo", and you'd get
> an error because Bar.Foo is a field, not a type. Now the type of "baz"
> resolves to the message type Foo. This change is unlikely to make a
> difference to anyone who follows the Protocol Buffers style guide.
You did not fix this similar case, where the "int32 Baz" field causes
an error when trying to extend the "message Baz":
package test_resolve;
message Foo {
optional int32 Baz = 2;
extend Baz {
optional int32 nonsense = 76335;
}
}
message Baz {
extensions 100 to max;
}
I will make the Haskell version compatible with protoc-2.1.0 but
perhaps you want to make the above a legal proto file in the future.
What do people think?
--~--~-~--~~~---~--~~
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
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
Re: 2.1.0 release is up
Kenton Varda wrote:
> 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 blob using the "length-delimited" wire type. Within
> this blob, the individual values are encoded the same way they would
> be normally except without a tag before each value (thus, they are
> tightly "packed").
I see http://code.google.com/apis/protocolbuffers/docs/proto.html has
been updated.
I will add Haskell support for this.
> * For each field, the generated code contains an integer constant
> assigned
> to the field number. For example, the .proto file:
> message Foo { optional int bar_baz = 123; }
> would generate the following constants, all with the integer value
> 123:
> C++: Foo::kBarBazFieldNumber
> Java:Foo.BAR_BAZ_FIELD_NUMBER
> Python: Foo.BAR_BAZ_FIELD_NUMBER
> Constants are also generated for extensions, with the same naming
> scheme.
> These constants may be used as switch cases.
Currently the wire layer has the field number baked in; it is never
exposed except through the reflection API.
Not hard to define a bunch of Int values. But in Haskell these cannot
be used as case targets. To do that I have to create the Int values as
Enum constructors. Which is less good.
For now I'll just ignore them, and add a note about it to the user.
This will be a demand driven feature.
> other version of Google Test if needed.
> * It is now an error to define a default value for a repeated field.
> Previously, this was silently ignored (it had no effect on the
> generated
> code).
easy
> * Fields can now be marked deprecated like:
> optional int32 foo = 1 [deprecated = true];
> Currently this does not have any actual effect, but in the future
> the code
> generators may generate deprecation annotations in each language.
easy
> protoc
> * The type name resolver will no longer resolve type names to
> fields. For
> example, this now works:
> message Foo {}
> message Bar {
> optional int32 Foo = 1;
> optional Foo baz = 2;
> }
> Previously, the type of "baz" would resolve to "Bar.Foo", and
> you'd get
> an error because Bar.Foo is a field, not a type. Now the type of
> "baz"
> resolves to the message type Foo. This change is unlikely to make a
> difference to anyone who follows the Protocol Buffers style guide.
Ack, the Haskell version needs to be updated to track this change.
This means I have to go back and understand the name resolution module
in my Haskell implementation.
Hmmm
It currently has a "resolve in environment" that returns the first hit.
I'll have to update that.
> C++
> * DescriptorPool::AllowUnknownDependencies() may be used to tell
> DescriptorPool to create placeholder descriptors for unknown entities
> referenced in a FileDescriptorProto. This can allow you to parse
> a .proto
> file without having access to other .proto files that it imports, for
> example.
hmmmodd.
> Java
> * New I/O methods parseDelimitedFrom(), mergeDelimitedFrom(), and
> writeDelimitedTo() read and write "delemited" messages from/to a
> stream,
> meaning that the message size precedes the data. This way, you
> can write
> multiple messages to a stream without having to worry about delimiting
> them yourself.
This will help responding to that FAQ.
--~--~-~--~~~---~--~~
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
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
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 for length-prefixed messages > > Yes, native support for this kind of feature would be very welcome. > > -- > Wbr, > Antony Dovgal > > > > --~--~-~--~~~---~--~~ 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 protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: 2.1.0 release is up
On 14.05.2009 18:18, clint.foster wrote: > It's very nice to see support in the API for length-prefixed messages Yes, native support for this kind of feature would be very welcome. -- Wbr, Antony Dovgal --~--~-~--~~~---~--~~ 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 protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: 2.1.0 release is up
It's very nice to see support in the API for length-prefixed messages and blocking RPC's. Both will reduce the amount of boilerplate code needed for many protobuf applications. --~--~-~--~~~---~--~~ 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 protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: 2.1.0 release is up
Good job, Kenton! Thanks for your efforts. Ciao, Peter K. --~--~-~--~~~---~--~~ 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 protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
Re: 2.1.0 release is up
Thanks for releasing! On Wed, May 13, 2009 at 4:04 PM, Kenton Varda wrote: > 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. Good enough, these things happen. Thanks for your continuous support and hard work! -h --~--~-~--~~~---~--~~ 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 protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~--~~~~--~~--~--~---
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
> * 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 blob using the "length-delimited" wire type. Within
> this blob, the individual values are encoded the same way they would
> be normally except without a tag before each value (thus, they are
> tightly "packed").
> * For each field, the generated code contains an integer constant
> assigned
> to the field number. For example, the .proto file:
> message Foo { optional int bar_baz = 123; }
> would generate the following constants, all with the integer value 123:
> C++: Foo::kBarBazFieldNumber
> Java:Foo.BAR_BAZ_FIELD_NUMBER
> Python: Foo.BAR_BAZ_FIELD_NUMBER
> Constants are also generated for extensions, with the same naming
> scheme.
> These constants may be used as switch cases.
> * Updated bundled Google Test to version 1.3.0. Google Test is now
> bundled
> in its verbatim form as a nested autoconf package, so you can drop in
> any
> other version of Google Test if needed.
> * optimize_for = SPEED is now the default, by popular demand. Use
> optimize_for = CODE_SIZE if code size is more important in your app.
> * It is now an error to define a default value for a repeated field.
> Previously, this was silently ignored (it had no effect on the
> generated
> code).
> * Fields can now be marked deprecated like:
> optional int32 foo = 1 [deprecated = true];
> Currently this does not have any actual effect, but in the future the
> code
> generators may generate deprecation annotations in each language.
> * Cross-compiling should now be possible using the --with-protoc option
> to
> configure. See README.txt for more info.
>
> protoc
> * --error_format=msvs option causes errors to be printed in Visual Studio
> format, which should allow them to be clicked on in the build log to go
> directly to the error location.
> * The type name resolver will no longer resolve type names to fields.
> For
> example, this now works:
> message Foo {}
> message Bar {
> optional int32 Foo = 1;
> optional Foo baz = 2;
> }
> Previously, the type of "baz" would resolve to "Bar.Foo", and you'd get
> an error because Bar.Foo is a field, not a type. Now the type of "baz"
> resolves to the message type Foo. This change is unlikely to make a
> difference to anyone who follows the Protocol Buffers style guide.
>
> C++
> * Several optimizations, including but not limited to:
> - Serialization, especially to flat arrays, is 10%-50% faster, possibly
> more for small objects.
> - Several descriptor operations which previously required locking no
> longer
> do.
> - Descriptors are now constructed lazily on first use, rather than at
> process startup time. This should save memory in programs which do
> not
> use descriptors or reflection.
> - UnknownFieldSet completely redesigned to be more efficient
> (especially in
> terms of memory usage).
> - Various optimizations to reduce code size (though the serialization
> speed
>optimizations increased code size).
> * Message interface has method ParseFromBoundedZeroCopyStream() which
> parses
> a limited number of bytes from an input stream rather than parsing
> until
> EOF.
> * GzipInputStream and GzipOutputStream support reading/writing gzip- or
> zlib-compressed streams if zlib is available.
> (google/protobuf/io/gzip_stream.h)
> * DescriptorPool::FindAllExtensions() and corresponding
> DescriptorDatabase::FindAllExtensions() can be used to enumerate all
> extensions of a given type.
> * For each enum type Foo, protoc will generate functions:
> const string& Foo_Name(Foo value);
> bool Foo_Parse(const string& name, Foo* result);
> The former returns the name of the enum constant corresponding to the
> given
> value while the latter finds the value corresponding to a name.
> * RepeatedField and RepeatedPtrField now have back-insertion iterators.
> * String fields now have setters that take a char* and a size, in
> addition
> to the existing ones that took char* or const string&.
> * DescriptorPool::AllowUnknownDependencies() may be used to tell
> DescriptorPool to create placeholder descriptors for unknown entities
> referenced in a FileDescriptorProto. This can allow you to parse a
> .proto
> file without having access to other .proto files that it imports, for
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 blob using the "length-delimited" wire type. Within
this blob, the individual values are encoded the same way they would
be normally except without a tag before each value (thus, they are
tightly "packed").
* For each field, the generated code contains an integer constant assigned
to the field number. For example, the .proto file:
message Foo { optional int bar_baz = 123; }
would generate the following constants, all with the integer value 123:
C++: Foo::kBarBazFieldNumber
Java:Foo.BAR_BAZ_FIELD_NUMBER
Python: Foo.BAR_BAZ_FIELD_NUMBER
Constants are also generated for extensions, with the same naming
scheme.
These constants may be used as switch cases.
* Updated bundled Google Test to version 1.3.0. Google Test is now
bundled
in its verbatim form as a nested autoconf package, so you can drop in
any
other version of Google Test if needed.
* optimize_for = SPEED is now the default, by popular demand. Use
optimize_for = CODE_SIZE if code size is more important in your app.
* It is now an error to define a default value for a repeated field.
Previously, this was silently ignored (it had no effect on the generated
code).
* Fields can now be marked deprecated like:
optional int32 foo = 1 [deprecated = true];
Currently this does not have any actual effect, but in the future the
code
generators may generate deprecation annotations in each language.
* Cross-compiling should now be possible using the --with-protoc option to
configure. See README.txt for more info.
protoc
* --error_format=msvs option causes errors to be printed in Visual Studio
format, which should allow them to be clicked on in the build log to go
directly to the error location.
* The type name resolver will no longer resolve type names to fields. For
example, this now works:
message Foo {}
message Bar {
optional int32 Foo = 1;
optional Foo baz = 2;
}
Previously, the type of "baz" would resolve to "Bar.Foo", and you'd get
an error because Bar.Foo is a field, not a type. Now the type of "baz"
resolves to the message type Foo. This change is unlikely to make a
difference to anyone who follows the Protocol Buffers style guide.
C++
* Several optimizations, including but not limited to:
- Serialization, especially to flat arrays, is 10%-50% faster, possibly
more for small objects.
- Several descriptor operations which previously required locking no
longer
do.
- Descriptors are now constructed lazily on first use, rather than at
process startup time. This should save memory in programs which do
not
use descriptors or reflection.
- UnknownFieldSet completely redesigned to be more efficient (especially
in
terms of memory usage).
- Various optimizations to reduce code size (though the serialization
speed
optimizations increased code size).
* Message interface has method ParseFromBoundedZeroCopyStream() which
parses
a limited number of bytes from an input stream rather than parsing until
EOF.
* GzipInputStream and GzipOutputStream support reading/writing gzip- or
zlib-compressed streams if zlib is available.
(google/protobuf/io/gzip_stream.h)
* DescriptorPool::FindAllExtensions() and corresponding
DescriptorDatabase::FindAllExtensions() can be used to enumerate all
extensions of a given type.
* For each enum type Foo, protoc will generate functions:
const string& Foo_Name(Foo value);
bool Foo_Parse(const string& name, Foo* result);
The former returns the name of the enum constant corresponding to the
given
value while the latter finds the value corresponding to a name.
* RepeatedField and RepeatedPtrField now have back-insertion iterators.
* String fields now have setters that take a char* and a size, in addition
to the existing ones that took char* or const string&.
* DescriptorPool::AllowUnknownDependencies() may be used to tell
DescriptorPool to create placeholder descriptors for unknown entities
referenced in a FileDescriptorProto. This can allow you to parse a
.proto
file without having access to other .proto files that it imports, for
example.
* Updated gtest to latest version. The gtest package is now included as a
nested autoconf package, so it should be able to drop new versions into
the
"gtest" subdirectory without modification.
Java
* Fixed bug where Message.mergeFrom(Message) failed to merge extensions.
* Message interface has new method toBuilder() which is equivalent to
newBuilderForType().mergeFrom(this).
