Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FI Microsoft/bond/master => lokitoth/bond/master #1

Merged
merged 242 commits into from Dec 8, 2015

Conversation

lokitoth
Copy link
Owner

@lokitoth lokitoth commented Dec 8, 2015

No description provided.

sapek and others added 30 commits January 10, 2015 15:28
CMake Visual Studio generator translates add_custom_command into a batch
file embedded in Visual Studio project. Batch files have problems with
paths that contain non-ascii characters because they are limited to DOS
encoding. It so happens that cabal is quite likely to be installed in
such a path because by default cabal installs into a directory under
%APPDATA% which contains user name. As a workaround we execute cmake
scripts as a custom commands and depend on CMake cache to get access to
variables set during configuration. This way embedded batch files are
free of non-ascii characters.
Fix compiler CMake permissions for OSX
Fix a typo in documentation
OutputBuffer implements IOutputStream not IOutputBuffer.
Custom actions in Visual Studio projects are executed as batch files.
If cmake is also a batch file then the statement:

        cmake ...

will call cmake.bat and never return from it. Replacing it with:

        call cmake ...

makes sure that the custom command batch file continues after cmake
returns.
This project was more of a playground than a proper example. It was
never included in cs.sln.
For now only configuring OS X build. Travis-CI runs Linux builds on
Ubuntu 12.04 for which pre-built Boost packages end at 1.48. Bond
currently requires 1.54.
Update OS X instruction for homebrew Python
Use Homebrew to install cmake, ghc and cabal-install instead of CMake
and Haskell Platform manual installations.
Rename Bond.cs to Bond.CSharp and Bond.Runtime.cs to Bond.Runtime.CSharp.

The old packages on nuget.org are converted to redirect packages that
are empty and only have dependency on the new packages.
The compiler now supports C++11 defaulted functions. Since Boost config
doesn't detect features for the new compiler yet, we ignore
BOOST_NO_CXX11_DEFAULTED_FUNCTIONS macro when _MSC_VER > 1900.
Use multi-line string both in the JSON input and the verification assert.
By default the blob type maps in C# to ArraySegment<byte>. This choice
is dictated by performance: using ArraySegment rather than a simple
array allows deserializer to avoid memcpy.

At the same time arrays are often a very convenient type in C# and Bond
supports T[] as an alternative mapping for the schema type vector<T>.
Although C# codegen doesn't generate arrays by default, users can either
manually annotate array fields in their own classes with Bond attributes
or they can use custom type alias mapping support (the gbc command line
option --using) to generate classes with array fields.

This change optimizes how C# byte[] is handled by object parser as well
as serializer and deserializer transforms. Instead of reading/writing
each byte individually, which is very expensive, when possible Bond will
use fast block operations exposed by IUntaggedProtocolReader.ReadBytes,
ITaggedProtocolReader.ReadBytes, IProtocolWriter.WriteBytes and
IParser.Blob.

It is important to note that even though byte[] gets the performance
optimizations associated with blob, it is not the same as schema blob
type. On the wire blob is represented as vector<int8> and C# byte[] maps
to vector<uint8>. It is of course possible to map byte[] to schema blob
type via an explicit type annotation:

    [global::Bond.Id(0), global::Bond.Type(typeof(global::Bond.Tag.blob))]
    public byte[] Arr { get; set; }

The same can be achieved using type aliases:

    using ArrayBlob = blob;
    struct Foo
    {
        0: ArrayBlob data = nothing;
    }

    gbc --using="ArrayBlob=byte[]" foo.bond

Representing blob using a byte[] instead of the default
ArraySegment<byte> is still a performance compromise because it requires
memcpy during deserialization. In some cases the convenience of byte[]
may justify it but for optimal performance ArraySegment<byte> is
recommended. To make this trade-off clear, aliasing blob as byte[]
requires that user provides explicit type converter, like for any other
type alias.
Looks like AppVeyor doesn't support YAML line continuations.
The bug in the parser caused it to interpret any default value starting
with the letter L as a string literal, resulting in a parsing error for
constructs like:

    struct Foo
    {
        0: Verbosity verbosity = Low;
    }
sapek and others added 27 commits November 14, 2015 20:59
Integer limits tests need an exception because Newtonsoft JSON
doesn't support support unsigned int64. Rewritten the test so that all
limits are tested by default and only this one case is excluded for
JSON.
Integer limits tests need an exception because Newtonsoft JSON
doesn't support support unsigned int64. Rewritten the test so that all
limits are tested by default and only this one case is excluded for
JSON.
The code was unnecessary going into slow path when decoding full size
varint at the end of payload.

Added an explicit test case since non-zero varint can never naturally
occur in the current set of binary protocols (tagged protocols never
have integer at the end of payload and Simple Binary, the only untagged
protocol currently shipping with Bond, uses varint only for
string/container length which also can't occur at the ned of payload).
C# classes with a static constructor (either added via partial class
extension of a generated class or in manually defined class annotated
with Bond attributes) would generate invalid expression tree for
deserializer.
Fix extra ref count on blob to PyBytes conversion
Add implementation of IInputStream and IOutputStream on top of unmanaged
memory buffer.

Note that unlike other IOutputStream implementations, the OutputPointer
does not have the ability to grow because it does not have ownership of
the memory involved.

Fixes #92.
We want Bond Nuget package to target .NET Core 5.0 and 7.0.1 is the
first version of Newtonsoft.Json supporting dnxcore50 as the target in
its Nuget package.
The C++ codegen failed to detect the need to generate #include <blob.h>
when the only use of blob was a field with default `nothing`.

For aliases of types that require extra header files the trigger should
be the alias usage rather than alias declaration.

Types of fields of base schema should not be considered.
Running:

    gbc schema --runtime-schema example.bond

will generate SchemaDef for each non-generic struct defined in the .bond
file(s). The SchemaDef(s) will be serialized using Simple JSON protocol
into file(s) named <source-file-name>.<struct-name>.json.

Fixes #75.
The word 'Schema' is a reserved name in Bond lexer because it conflicts
with the Schema struct in the generated C++ code. In order to support
some legacy schema definitions we are relaxing the restriction, allowing
the word to be used as part of namespace identifiers. The word Schema in
a namespace identifier does not conflict with the Schema struct in the
generated C++ code.
By default bonded<T> is represented by IBonded<T> and implemented by one
of the built-in Bonded classes. This change allows users to define a
custom type to represent bonded<T>. The type must implement IBonded
interface and can be instantiated during de-serialization either using
regular `new` (the constructor must take one argument of type IBonded)
or with a user defined factory. The latter allows more seamless support
for polymorphism during de-serialization because the factory can
determine the type at runtime from the payload represented by IBonded
argument.
The protocol reader R in Bonded<T, R> must be clonable, i.e. it must
implement IClonable<R> interface. Usually R is a specific protocol
implementation however it is also possible to use an interface (1). This
change defines new protocol reader interfaces which are clonable.

(1) Instantiating Deserializer for a protocol reader interface rather than a
specific protocol implementation trades off performance for the ability to
use the same Deserializer with different protocols.
In regular codegen the [Type(typeof(Bond.Tag.bonded<Foo>)] annotation is
not necessary because IBonded<T> already identifies the type as bonded<T>.
@lokitoth lokitoth self-assigned this Dec 8, 2015
lokitoth added a commit that referenced this pull request Dec 8, 2015
FI Microsoft/bond/master => lokitoth/bond/master
@lokitoth lokitoth merged commit d355949 into lokitoth:master Dec 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet