* Enable flatbuffer to initialize Parser from bfbs (#4283)
Now its possible to generate json data from bfbs data type and flatbuffers data
and visa versa.
* add deserialize functionality in parser from bfbs
* add small usage sample
* Fix build break
* Merge branch 'pr/1' into fix-issue4283
* Fix buildbreak
* Build monster_test.bfbs with --bfbs-builtins
Attribute flexbuffer has be included in bfbs. Only with this attribute test
will run. By initialization a parser by a bfbs the attribute has to be known
for this filed. monsterdata_test.golden has a flexbuffer field so parse would
fail.
* Fix generate_code.sh
* Revert automatic indent changes by IDE
* Auto detect size prefixed binary schema files
* Use identifier (bfbs) to detect schema files
* Refactoring of numbers parser
More accurate parse of float and double.
Hexadecimal floats.
Check "out-of-range" of uint64 fields.
Check correctness of default values and metadata.
* Remove locale-independent code strtod/strtof from PR #4948.
* small optimization
* Add is_(ascii) functions
* is_ascii cleanup
* Fix format conversation
* Refine number parser
* Make code compatible with Android build
* Remove unnecessary suppression of warning C4127
This is a port of FlatBuffers to Rust. It provides code generation and a
runtime library derived from the C++ implementation. It utilizes the
Rust type system to provide safe and fast traversal of FlatBuffers data.
There are 188 tests, including many fuzz tests of roundtrips for various
serialization scenarios. Initial benchmarks indicate that the canonical
example payload can be written in ~700ns, and traversed in ~100ns.
Rustaceans may be interested in the Follow, Push, and SafeSliceAccess
traits. These traits lift traversals, reads, writes, and slice accesses
into the type system, providing abstraction with no runtime penalty.
* starting Lua port of python implmention. Syncing commit
* Bulk of Lua module port from Python done. Not tested, only static analysis. Need to work on binary strings. Started work on flatc lua code generation
* Fixed all the basic errors to produced a binary output from the builder, don't know if it is generated correctly, but it contains data, so that must be good
* fixed binary set command that was extending the array improperly
* continued improvement
* Moved lua submodules down a directory so their names don't clash with potential other modules. Added compat module to provide Lua versioning logic
* Successful sample port from Python
* working on testing Lua code with formal tests
* continued to work on tests and fixes to code to make tests pass
* Added reading buffer test
* Changed binaryarray implmentation to use a temporary table for storing data, and then serialize it to a string when requested. This double the rate of building flatbuffers compared to the string approach.
* Didn't need encode module as it just added another layer of indirection that isn't need
* profiled reading buffers, optimizations to increase read performance of monster data to ~7 monster / millisecond
* Writing profiler improvments. Get about
~2 monsters/millisecond building rate
* removed Numpy generation from Lua (came from the Python port)
* math.pow is deprecated in Lua 5.3, so changed to ^ notation. Also added .bat script for starting Lua tests
* adding results of generate_code.bat
* simple edits for code review in PR.
* There was a buffer overflow in inserting the keywords into the unorder set for both the Lua and Python code gens. Changed insertion to use iterators.
* fixed spacing issue
* basic documenation/tutorial updates. Updated sample_binary.lua to reflect the tutorial better
* removed windows-specific build step in Lua tests
* initial changes to support size prefixed buffers in Java
* add slice equivalent to CSharp ByteBuffer
* resolve TODO for slicing in CSharp code generation
* add newly generated Java and CSharp test sources
* fix typo in comment
* add FinishSizePrefixed methods to CSharp FlatBufferBuilder as well
* add option to allow writing the prefix as well
* generate size-prefixed monster binary as well
* extend JavaTest to test the size prefixed binary as well
* use constants for size prefix length
* fuse common code for getRootAs and getSizePrefixedRootAs
* pulled file identifier out of if
* add FinishSizePrefixed, GetSizePrefixedRootAs support for Python
* Revert "extend JavaTest to test the size prefixed binary as well"
This reverts commit 68be4420dd.
* Revert "generate size-prefixed monster binary as well"
This reverts commit 2939516fdf.
* fix ByteBuffer.cs Slice() method; add proper CSharp and Java tests
* fix unused parameter
* increment version number
* pulled out generated methods into separate utility class
* pulled out generated methods into separate utility class for Python
* fix indentation
* remove unnecessary comment
* fix newline and copyright
* add ByteBufferUtil to csproj compilation
* hide ByteBuffer's internal data; track offset into parent's array
* test unsafe versions as well; compile and run in debug mode
* clarify help text for size prefix
* move ByteBuffer slicing behavior to subclass
* fix protection levels
* add size prefix support for text generation
* add ByteBufferSlice to csproj compilation
* revert size prefix handling for nested buffers
* use duplicate instead of slice for removing size prefix
* remove slice subclass and use duplicate for removing size prefix
* remove slice specific tests
* remove superfluous command line option
* Eclipse ignore
* TypeScript support
* Prefixing enums
* Test results
* Merged JS and TS generators
* Fixed AppVeyor build problems
* Fixed more AppVeyor build problems
* Fixed more AppVeyor build problems
* Changed TS flag to options struct
* Storing options by value
* Removed unneeded const
* Re-export support for unions
* Uint support
* Casting bools to numbers for mutation
* TS shell tests
* Reverted generates js test file to original version
* Backing up js tests and properly generating test data
* Not importing flatbuffers for TS test generation
* Not overwriting generated js for tests
* AppVeyor test fixes
* Generating the most strict TS code possible
* Not returning null when creating vectors
* Not returning null from struct contructors
* Vector of unions for ts/js
* Sanity check for languages
* Indentation fix + output test files
* Vectors of unions for php
* Fixes to union vector handling + tests
* Added internal - limited - implementation of flatbuffers::unique_ptr
for STLs that don't ship with std::unique_ptr. In C++11 and beyond
this is just an alias for std::unique_ptr.
* Aliased used type traits structs is_scalar is_floating_point is_unsigned
into flatbuffers namespace so they can be replaced in C++98 implementations.
Right now these point at stlport's TR1 implementations.
* Wrapped vector::data() in vector_data().
* Wrapped vector::emplace_back() in vector_emplace_back().
* Wrapper string::back() in string_back().
* Added variants of FlatBufferBuilder::CreateVector() and
FlatBufferBuilder::CreateVectorOfStructs() that allow the use of plain
function pointers.
Generated code has also been modified to use plain functions to build objects
rather than std::function() so all generated code will work in C++98
applications.
* Added flexbuffers::Builder::Vector(), flexbuffers::Builder::TypedVector()
and flexbuffers::Builder::Map() methods that allow the use of plain function
pointers.
* Changed Parser to internally use plain function pointers when parsing table
and vector delimiters.
* Added specializations of NumToString() for 64-bit types that aren't supported
by stringstream in stlport.
* Overloaded numeric_limits for 64-bit types not supported by stlport.
* Replaced build_apk.sh (which was broken by deprecation of the
"android" tool in the Android SDK) with build.gradle and the
appropriate gradle wrapper to build an APK.
* Switched Android build to build against all STL variants.
* Updated travis configuration to build Android test and sample.
Tested:
* Verified all tests continue to work on Linux, OSX and Android.
* Verified Travis build is green.
Change-Id: I9e634363793f85b9f141d21454b10686020a2065
* Eclipse ignore
* TypeScript support
* Prefixing enums
* Test results
* Merged JS and TS generators
* Fixed AppVeyor build problems
* Fixed more AppVeyor build problems
* Fixed more AppVeyor build problems
* Changed TS flag to options struct
* Storing options by value
* Removed unneeded const
* Re-export support for unions
* Uint support
* Casting bools to numbers for mutation
* TS shell tests
* Reverted generates js test file to original version
* Backing up js tests and properly generating test data
* Not importing flatbuffers for TS test generation
* Not overwriting generated js for tests
* AppVeyor test fixes
* Eclipse ignore
* TypeScript support
* Prefixing enums
* Test results
* Merged JS and TS generators
* Fixed AppVeyor build problems
* Fixed more AppVeyor build problems
* Fixed more AppVeyor build problems
* Changed TS flag to options struct
* Storing options by value
* Removed unneeded const
* Re-export support for unions
* Uint support
* Casting bools to numbers for mutation
* TS shell tests
* Reverted generates js test file to original version
* Backing up js tests and properly generating test data
This avoid to put the pom.xml file into the source directory. Normally the pom file is in a parent (/parent) folder and it is not mixed with the java source code.
An other thing is: this will make import of the project more easy from a IDE.
The side effect is that the target folder where maven build artifacts will move from the <flatbuffers>/java/target to <flatbuffers>/target therefore the gitignore file has been updated in consequences.
Java developer are mostly comfortable with maven project structure. One one the main concept behind maven is convention. If you follow the maven project convention then your development team will get more effective as they now this project structure and can easily find the production code versus the test code.
In this pull request I have structured the java project around 2 main parts:
* the `flatbuffers` project. This project is the api / lib project and contains the test code structure + an example of code generation for testing. This avoid to commit generated code. Pre-configure JUnit for test driven development and make this project OSGi compliant.
* the `jmh` project. This project aims to provide a placeholder for micro-benchmarking. JMH is a 'de facto' standard for micro benchmarking you can find more details here: http://openjdk.java.net/projects/code-tools/jmh/
For now I didn't move the JavaTest class but it could be a next step with a migration to the JUnit framework.
The only impacts are the move of the class and the project structure => no code change.
JavaScript uses UTF-16 but FlatBuffers uses UTF-8. This commit tests the code
that does the conversion between the two encodings. The last entry in the array
is tricky because each code point actually requires two UTF-16 code units,
unlike the other examples. The current JSON output of flatc actually handles
this case incorrectly (it generates invalid JSON with UTF-8 code units). The
generated JavaScript code passes these tests fine, however.
This adds a JavaScript language target. The generated JavaScript uses Google
Closure Compiler type annotations and can be compiled using the advanced
compilation mode, which performs type checking and optimizations such as
inlining and dead code elimination. The generated JavaScript also exports all
generated symbols for use with Node.js and RequireJS. This export behavior
can be turned off with the --no-js-exports flag for use with Google Closure
Compiler.
Implement code generation and self-contained runtime library for Python.
The test suite verifies:
- Correctness of generated Python code by comparing output to that of
the other language ports.
- The exact bytes in the Builder buffer during many scenarios.
- Vtable deduplication correctness.
- Edge cases for table construction, via a fuzzer derived from the Go
implementation.
- All code is simultaneously valid in Python 2.6, 2.7, and 3.4.
The test suite includes benchmarks for:
- Building 'gold' data.
- Parsing 'gold' data.
- Deduplicating vtables.
All tests pass on this author's system for the following Python
implementations:
- CPython 2.6.7
- CPython 2.7.8
- CPython 3.4.2
- PyPy 2.5.0 (CPython 2.7.8 compatible)
We were looking for 'flatc' in motive/bin/Debug/flatc,
on Mac. It's actually built to flatbuffers/Debug/flatc.
Tested: OS X Yosemite, ndk-r10d. Also tested on Linux.
Change-Id: I9f1ecfe00c5f42fd9b6808b5a5da1c920487a4c2
FlatBuffer schema files can now optionally specify a hash attribute that
will allow someone writing json files to enter a string to be hashed
rather than a specific value. The hashing algorithm to use is specified
by the schema.
Currently the only algorithms are fnv1 and fnv1a. There are 32 bit and
64 variatns for each. Additionally, a hashing command line tool was
added so that you can see what a string will hash to without needing to
inspect the flatbuffer binary blob.
Change-Id: I0cb359d0e2dc7d2dc1874b446dc19a17cc77109d
Include C# codegen in flatc and .NET FlatBuffer access via the
FlatBufferBuilder class
Tested: on Windows.
Change-Id: If5228a8df60a10e0751b245c6c64530264ea2d8a
Allows you to add, and test for the presence of a magic 4-char
string in a FlatBuffer.
Tested: on OS X.
Change-Id: I090692a9e4fb53bed3543279a28563e67132cba0
Implement code generation and runtime library for Go, derived from the
Java implementation. Additionally, the test suite verifies:
- the exact bytes in the Builder buffer during object construction,
- vtable deduplication, and
- table construction, via a fuzzer derived from the C++ implementation.
Change-Id: Ib95a019c684891def2b50281e570b4843fea7baa
tira-misu