MessageType
), creating a Prolog term.
Protoc
must have been run (with the --swipl_out=
option and the resulting top-level _pb.pl
file loaded. For
more details, see the "protoc" section of the overview documentation.
Fails if the message can't be parsed or if the appropriate meta-data
from protoc
hasn't been loaded.
All fields that are omitted from the WireCodes
are set
to their default values (typically the empty string or 0, depending on
the type; or []
for repeated groups). There is no way of
testing whether a value was specified in WireCodes
or given
its default value (that is, there is no equivalent of the Python
implementation's =HasField`). Optional embedded messages and groups do
not have any default value -- you must check their existence by using get_dict/3
or similar. If a field is part of a "oneof" set, then none of the other
fields is set. You can determine which field had a value by using get_dict/3.
WireCodes | Wire format of the message from
e.g., read_stream_to_codes/2. (The stream
should have options encoding(octet) and type(binary) ,
either as options to read_file_to_codes/3
or by calling set_stream/2 on the stream
to read_stream_to_codes/2.) |
MessageType | Fully qualified message name
(from the .proto file's package and message ).
For example, if the package is google.protobuf
and the message is FileDescriptorSet , then you would use
'.google.protobuf.FileDescriptorSet' or 'google.protobuf.FileDescriptorSet' .
If there's no package name, use e.g.: 'MyMessage or '.MyMessage' .
You can see the packages by looking at
protobufs:proto_meta_package(Pkg,File,_) and the message
names and fields by
protobufs:proto_meta_field_name('.google.protobuf.FileDescriptorSet', FieldNumber, FieldName, FqnName)
(the initial’.’is not optional for these facts, only for the
top-level name given to protobuf_serialize_to_codes/3). |
Term | The generated term, as nested dicts. |
- Errors
version_error(Module-Version)
you need to recompile theModule
with a newer version ofprotoc
.- See also
library(protobufs)
: Google's Protocol Buffers (section 1.3.1)- bug
- - Ignores
.proto
extensions.
-map
fields don't get special treatment (but see protobuf_map_pairs/3).
- Generates fields in a different order from the C++, Python, Java implementations, which use the field number to determine field order whereas currently this implementation uses field name. (This isn't stricly speaking a bug, because it's allowed by the specification; but it might cause some surprise.) - To be done
- - document the generated terms (see
library(http/json)
and json_read_dict/3)
- add options such astrue
andvalue_string_as
(similar to json_read_dict/3)
- add option for form of the dict tags (fully qualified or not)
- add option for outputting fields in the C++/Python/Java order (by field number rather than by field name).