ktakashi/r6rs-protobuf

Forked from code.google.com/p/r6rs-protobuf

r6rs-protobuf's Issues

error in library: attempt to export unbound identifier protobuf:field-type-message

What steps will reproduce the problem?
1. Download r6rs-protobufy
2. make a file rethink-scheme.scm with:

;; Copyright Marcelo Costa Toyama - [email protected] 2013

(import (protobuf compile))

;(define proto (protoc:read-proto (open-input-file "ql2.proto")))
;(protoc:generate-libraries proto)

3. run ./ypislon or plt-r6rs (racket).

What is the expected output? What do you see instead?

The following error appears

root@debian:~/rethink-scheme# ./ypsilon --sitelib="." rethink-scheme.scm

error in library: attempt to export unbound identifier 
protobuf:field-type-message
  >  (export protobuf:make-field-type-descriptor
             protobuf:field-type-descriptor-default
             protobuf:field-type-descriptor-name
             protobuf:field-type-descriptor-predicate
             protobuf:field-type-descriptor-wire-type
       ...
  ..."/root/rethink-scheme/protobuf/private.scm" line 20



What version of the product are you using? On what operating system?
I am using 
r6rs-protobuf-0.6.tar.gz

Debian jessie (debian testing).

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 17 Oct 2013 at 2:34

Non-primitive field types are not supported.

The parser and code generator should support enums and messages as field types.

Original issue reported on code.google.com by [email protected] on 31 Mar 2011 at 3:14

Repeated message fields are not supported

Repeated fields should be supported by the code generator and serialization 
system.

Original issue reported on code.google.com by [email protected] on 31 Mar 2011 at 3:11

Message readers should ignore unknown fields

...as per the protocol buffer wire protocol description.

Original issue reported on code.google.com by [email protected] on 31 Mar 2011 at 3:17

Field defaults not set on builder or message

What steps will reproduce the problem?
1. Set a default option on a field definition
2. Build a message without setting a value for the field

What is the expected output? What do you see instead?

The field should have the specified value in the builder and resulting message; 
no value is set.

Original issue reported on code.google.com by [email protected] on 20 May 2011 at 3:25

Nested message and enum definitions are not supported

Implement such that they produce qualified type names during code generation.

Original issue reported on code.google.com by [email protected] on 9 Apr 2011 at 3:03

Wrong order in generated fields

I found something wrong when I use 'Person-read' as the tutorial in
r6rs-protobuf site.

Here is the code:

-------------------------code-----------------------
...
(define pb (make-Person-builder))
(set-Person-builder-id! pb 1)
(set-Person-builder-name! pb "nalaginrut")
(set-Person-builder-email! pb "[email protected]")

(call-with-output-file "person.out"
  (lambda (port)
     (Person-write person port)))
(define person (Person-builder-build pb))

;; So far so good!
(define person2 (Person-read (open-input-file "person.out")))

(Person-id person2)
==> "[email protected]" 
;; hmm?
(Person-email person2)
==> 1
(Person-name person2)
==> "nalaginrut"

Original issue reported on code.google.com by [email protected] on 25 Jan 2013 at 3:08

Extensions are not supported

Implement as per the protocol buffer definition language specification.

Original issue reported on code.google.com by [email protected] on 9 Apr 2011 at 3:09

Length prefix of message fields not properly consumed during deserialization

What steps will reproduce the problem?
1. Create a protobuf with a message type field
2. Attempt to deserialize a serialized form of the message
3.

What is the expected output? What do you see instead?

Unpredictable corruption, particular in determining the types and contents of 
fields in the embedded message and in fields that come after it.

Please use labels and text to provide additional information.

The length prefix of the messages field is not being consumed.

Original issue reported on code.google.com by [email protected] on 1 Apr 2014 at 2:38