Don't override file extension for imports; assume the string that was
used to form the pathname is accurate. This makes base-path and
proto-file the same, so fold them both into proto-file.
Change how protobuf schemas and classes are recorded and found
* FIND-SCHEMA no longer works on a string or keyword. Both of these
were based on the PATHNAME-NAME of the protobuf, which has a high
probability of collision. (e.g., common.proto -> "COMMON", :COMMON)
Instead, look up schemas based on package and name. For instance,
the protobuf foo.proto, declaring "package FooPackage;", can be
found with: (FIND-SCHEMA 'FOO-PACKAGE::FOO)
* Pathname-based schema lookup no longer ignores file type.
* DO-PROCESS-IMPORT is now responsible for deciding whether or not to
process an import. It does so by searching for the .proto to be
imported, and upon finding it, checks to see if we alredy have a
schema for that pathname. Additionally, it now returns the pathname.
* PROCESS-IMPORTS and PROCESS-IMPORTS-FROM-FILE now defer the work of
figuring out whether or not an import has been done to
DO-PROCESS-IMPORT. PROCESS-IMPORTS uses the return value of
DO-PROCESS-IMPORT to update the PROTO-IMPORTED-SCHEMAS of the schema
being processed.
* ASDF::PROTOBUF-MANGLE-NAME: Takes a pathname, returns a string to be
used as a filename that represents the original path.
e.g., #P"/foo/bar/baz.quux" becomes "foo-bar-baz-quux"
* ASDF::PROTOBUF-LISPIZE-PATHNAME: Takes a pathname, returns a new
pathname with the name mangled as described above, and with a lisp
type.
Scott McKay [Sun, 3 Mar 2013 09:52:37 +0000 (15:22 +0530)]
In the spirit of making CL-Protobufs represent exemplary modern Common Lisp code:
- Use 'defparameter' instead of 'defvar' where appropriate.
- Fix 'defvar' doc strings to distinguish between globals and "thread locals".
- Avoid using 'nconc'. introduce a new 'appendf' macro instead.
- Add a comment lamenting the fact that exporting something like 'proto-options'
also exports the writer '(setf proto-options)'. Fixed in Dylan.
Don't assume that returning no options meant there was no body in the
method declaration. An empty body may have been there
instead. Distinguish that scenario with a second return value from
PARSE-PROTO-METHOD-OPTIONS and use that value in PARSE-PROTO-METHOD
determine whether or not to look for a semicolon.
printer.lisp: consume more arguments when appropriate
Here we should have been consuming both the thing we would be printing
and the indentation we would use on the next line, but in the case
where the printed thing was nil, we would only consume it, and not the
subsequent indentation. It worked out here, but the mistake could only
be made once, and only at the end.
Robert Brown's protobuf package falls back on the java_package option
as the lisp package name when there isn't a package declaration in the
schema. Emulate that behavior for better compatibility between code
generated by the packages.
Generate integer encoders and decoders with thought towards the size of a FIXNUM
Rather than hard-code assumptions about the size of a FIXNUM, check
the size of FIXNUM at compile time and generate code appropriate for
the number of bits we're working with, with FIXNUM optimizations
in place if appropriate.
"A common pattern is to define extensions inside the scope of the
extension's field type – for example, here's an extension to Foo of
type Baz, where the extension is defined as part of Baz"
Add a proper input-files method for proto-to-lisp,
which shall fix the issue that causes of these actions never being operation-done-p.
However this does NOT handle recursive import dependencies,
which requires further work.
Tested: QRes doesn't always recompile the proto and all dependees anymore.
Reviewer: asedeno
Ben Wagner [Tue, 20 Nov 2012 18:43:00 +0000 (13:43 -0500)]
fix cross-package and forward references in cl-protobufs
* Previously, if a field in a .proto file referenced a message in
another proto file using a different lisp package, the cl-protobufs
library would silently fail to serialize the field. A similar
problem would occur if a message defined later in the file used the
lisp_name option to override the name generated by cl-protobufs.
This change fixes these issues and others.
* Add conditions that are signaled when encountering an undefined
type.
* Delay assigning lisp classes/types to fields and methods until all
possible forward references have been parsed.
* This allows the class slot to be unbound, so check for that case
in print-object methods.
* Add a test for forward references to messages that override the
lisp name.
* Add a test for references to messages and enums defined in
another proto file with a different lisp package.
* Change color-wheel-stability test, because it used "string" as
the input type for an rpc, which seems to be disallowed (although
I haven't found this documented anywhere).
* Signal errors during parsing for undefined types.
* Add a test for these errors. Add assert-error macro to qtest.
* Signal a condition if we are unable to find the definition for a
field's type during serialization, deserialization, determining an
object's serialized size, printing text format, parsing text format,
or generating code for one of the above.
* Remove logic in find-qualified-name that indirects through lisp
packages. Proto packages and lisp packages do not necessarily map
1-to-1.
* Always use the schema's lisp package for any symbols generated when
parsing proto files.
* When generating lisp code using write-schema-as, set the package to
the package used in the generated file, so that ~s will print the
package prefix in the correct circumstances.
* Remove broken proto1 "streams" parsing ("returns" comes before
"streams" in every example I've found); replace with proto2 syntax.
* In process-imports, the call to find-schema using a pathname was not
giving the expected result. Sidestep this issue by using the same
logic to find the schema as is used earlier in the function.