More language bindings about fluid-engine-dev

[utilForever]

CubbyFlow provides APIs to support various languages such as Python, Go, Rust, and C #. If you like, I would like to help you support the Jet framework as well. Before that, I'm building a few repositories that generate code for each language in C++, like pybind11.

[doyubkim]

That would be great. What's the priority for those languages? I'm considering either Go or WinRT for the next pick.

[utilForever]

I am considering Python > Go = C# > Rust in order. But others have asked for Kotlin, JavaScript, Lua, and so on. So I'm thinking of implementing these languages as well.

[doyubkim]

(Just thinking out loud here)

Getting C# binding will be much easier, especially if we use C++/CX (WinRT). Go/Lua binding could be quite challenging due to the difference between C++ and these languages. But if we can come up with C-style (or actual C) wrapper around Jet Framework, that would make Go/Lua binding easier. Kotlin sounds fun, especially for mobile. For JS, it should be more like a porting rather than binding (or wasm?).

I'm now leaning toward C# and pure C wrapper (for Go and Lua) for the first pick, but let's keep the discussion continue for a while before we hear more opinions.

[utilForever]

First, I tried to use pybind11 to support the Python API. However, my code didn't use pybind11 because I used C++17 features. Therefore, we are creating pybind17 which supports it. Similarly, we are creating gobind17 and rustbind17. Of course this is not an easy challenge, but I will try to implement it once.

[utilForever]

Update: I recently started working on CubbyFlow to support the C# API. In order to support cross-platform, I am working on binding using a library called CppSharp (https://github.com/mono/CppSharp). If I get a good result, I'll also work on the Jet framework and get a pull request.

[doyubkim]

Amazing news! Thanks for the update, @utilForever. If we can have C# API alongside with Python API, it would be extremely useful.

[utilForever]

Update: I apologize for the delay in responding to implementation.
I was in the army for about a month and could not answer.
I'll resume work from today, so please be patient. Thanks.

[doyubkim]

@utilForever , no problem at all. Welcome back from the training.

[utilForever]

Update: I tried to use CppSharp to generate C# or C++/CLI code, but I decided not to use it because I had difficulty using it for various reasons. Instead, I started to write my own C++/CLI code and implement it for use in C#. As a result, I saw the possibility. I've implemented the Frame class for testing, and I've found success in a C# unit test project. I'll implement C++/CLI code for the rest of the code.

https://github.com/utilForever/CubbyFlow/blob/master/Includes/API/CSharp/Animation/Frame.h
https://github.com/utilForever/CubbyFlow/blob/master/Sources/API/CSharp/Animation/Frame.cpp
https://github.com/utilForever/CubbyFlow/blob/master/Sources/API/CSharp/CMakeLists.txt

NOTE: C++/CLI currently supports only the Windows platform. If you want to support cross-platform, I need to consider other methods such as .NET Core(P/Invoke and COM Interop). Alternatively, try using CppSharp again. I wonder if the C# API is okay on the Windows platform. (Please note that in .NET Core I must export CubbyFlow as a dll file. For example, https://blog.quickbird.uk/calling-c-from-net-core-759563bab75d)

[doyubkim]

@utilForever and I had an offline discussion and decided to revive my old prototype for both C++/CLI and CX. I will create a new branch (let's call it csharp branch) and port my old code there. It will provide the initial binding mechanism, but no actual wrapper codes. We can add actual wrappers and improve the binding code simultaneously.

The key requirements would be:

1. Should support both CLR and WinRT via C++/CLI and CX.
2. API should be extensible from C# (or other .NET languages), just like the existing C++ and Python API
3. (optional) Once both csharp and gpu branch becomes mature, DX renderer for WPF and WinRT could be added. We also have a prototype for this. Nice-to-have feature, but not a must.

[utilForever]

I have verified that the csharp branch has been created. It still have only an empty project, is the porting done? I would be grateful if you could inform me when it would be okay for me to start working.

[doyubkim]

Yup it is still empty. Porting would take some time. I will post my update once it’s ready :)

[doyubkim]

Proof-of-concept code is pushed to csharp branch.

• Both CLR and WinRT shares .cpp files. Language(?) dependent code is controlled with macros. I know it's ugly, but again, this is just a PoC. We can develop on top of this.
• Files under src/csharp/common contain the shared .cpp codes.
• Files under src/csharp/clr and src/csharp/winrt contain language specific codes. You will find macro.h files for both projects which defines the same macro interface, but different implementations.
• Both CLR and WinRT have minimal unit tests written in C#.

@utilForever please take a look.

[utilForever]

@doyubkim Thanks. I'll look at it.