Experience using Bridge.NET

[johnwason]

I am going to share my experience using Bridge.Net in the hope that the feedback is helpful to the developers. Overall I have been impressed with the project. I develop a robotics communication software package that I wanted to port to run in web browsers alongside the standard application implementations. I have a large existing C# codebase so the best option was to use a C# to JavaScript compiler. I was able to use Bridge.Net to implement a proof of concept where I was able to drive a robot using the HTML5 gamepad support, which is pretty neat. Eventually I'd like to be able to have a single codebase that runs both in .NET and Bridge.Net with as much shared code as possible. I ran into a few issues that make this difficult:

• The "lock" statement appears frequently in any multithreaded C# code. While it doesn't make sense in a browser it would be helpful if it came up as a warning instead of an error and was simply ignored.
• TaskCompletionSource and CancellationToken are very important to async/await code.
• Structures are not implemented properly for function parameters. For example,
  void f(CancellationToken cancel=default(CancellationToken)) {}
  is a standard usage.
• Various contiguous arrays such as byte[], int[], etc currently use JavaScript arrays. It would be better for my project if they used Uint8Array, Int32Array, etc.
• [DONE] Long types have no support and unpredictable behavior
• The System.IO namespace appears to be unimplemented. At least some basic support should be available as an extension package. Especially the exceptions like System.IO.TimeoutException should be available. While they are in the System.IO namespace they get used elsewhere.
• Some basic support for System.Net would be helpful along with System.Net.Websockets
• A wrapper class for the Gamepad objects would be cleaner than using "dynamic".
• A few general bugs that look like they have been fixed.

These suggestions are not necessarily critical but would be nice if they were available.

[johnwason]

Another comment:

• "undefined" is a strange concept in C#. Having it map to "null" would be easier to deal with.

[geoffrey.mcgill]

Hi johnwason,

Thanks for the great feedback!

We will review your points in detail and get back to you with a plan to implement. All the suggestions look very reasonable. I'm not sure what a js implementation of System.Net, System.Net.WebSockets and System.IO would look like, but we can start the process.

I'll look into producing a Gamepad->Bridge definition library. In general these are very easy to create. We might be able to get things started, then have others within the community help out.

At some point we would love to get a demo of what you're working on. Sounds very cool.

[johnwason]

In terms of the System.IO namespace, I think supporting Stream, Reader, Writer, and MemoryStream along with the readers/writers such as BinaryReader, BinaryWriter, TextReader, TextWriter etc would be sufficient. It would at least allow existing code that accepts a stream/reader/writer parameter. It occurs to me supporting the encoding classes would probably be necessary to help with the IO routines as well. For System.NET I am mainly missing the URI class. I think the ClientWebSocket class can simply wrap the built in browser WebSocket as it doesn't implement non-async members.

You can take a look at the documentation at https://robotraconteur.com/documentation/ for info about my project. The client browser implementation is identical to the other languages except running in the browser instead of as an application. I will be releasing a new version in a few months that has more features.

[Daniil]

Thank you for sharing a link to your project! It is very interesting and exciting what you are working on and happy to hear that Bridge helps.

I'll be creating issues and asking basing on your feedback. Please consider continuing specific discussions in related issues or forum threads. I mean discussing all the things in one thread might makes it very hard to maintain.

• The "lock" statement
• Could you, please, elaborate on these ones? Ideally, in the individual thread (-s) or GitHub issue (-s). I am just not very sure what issues to create for.

• TaskCompletionSource and CancellationToken are very important to async/await code.
• Structures are not implemented properly for function parameters. For example,
  void f(CancellationToken cancel=default(CancellationToken)) {}
  is a standard usage.

• TypedArrays instead of regular arrays. Interesting that the Issue has been just opened by another community member and a pull request has been submitted.
• long type
• System.IO
• System.Net
• Gamepad
• "undefined" concept

[guidovanhils]

Hello Bridge.Net team,

You really did great job!
I was first a bit skeptic but now it feels really that c# is the source code. :)
I have made a type-library for THREE.js (not complete yet) all is really working real fine.

Is there is anything new on angular.js for Brigde.Net?

Best regards,

Guido

[Daniil]

Hi @guidovanhils,

Welcome to the forums!

You really did great job!

Thank you very much!

I was first a bit skeptic but now it feels really that c# is the source code. :)

It is so great to hear that Bridge changes someone's mind in this manner:) Thank you very much for sharing!

Tweeted about it:)
https://twitter.com/bridgedotnet/sta...30349656379392

I have made a type-library for THREE.js (not complete yet) all is really working real fine.

Awesome! Please clarify is this being done publicly (GitHub repo or something)? I believe many people would love to give it a try:)

Is there is anything new on angular.js for Brigde.Net?

Angular (v1) has been partially implemented in Bridge v1:
https://github.com/bridgedotnet/Fram...ster/AngularJS

There is a demo.
https://github.com/bridgedotnet/Demo.../AngularJSDemo

If you give it a try, it would be great to hear your feedback:)

[guidovanhils]

Hi Daniil,

Thank you for your reply.

Awesome! Please clarify is this being done publicly (GitHub repo or something)? I believe many people would love to give it a try:)

As soon as it is a little more mature I will post it somewhere.

Best regards,

Guido

[geoffrey.mcgill]

Three.js topic has been moved to the following thread:

http://forums.bridge.net/forum/gener...for-bridge-net

[Daniil]

johnwason, just FYI. There are changes in the recent 1.11.0 release basing on your feedback.

• Now the lock statement (GitHub issue #777) is just ignored in emitted JavaScript code. All what is inside is emitted. Live Sample
• TypedArrays are now used instead of regular arrays (#772).
• The change regarding undefined (#782): now obj === null check will be emitted as !Bridge.hasValue(obj) that actually checks on both - null and undefined.
• TaskCompletionSource and CancellationToken were implemented (#790)

As for other items:

• The long support is under development (#778)
• System.IO (#779), System.Net (#780) and Gamepad (#781) are to decide on yet.

[johnwason]

Thanks for the update. I have finished the initial version of my library and will be releasing it in the next few weeks. I still require Int64 and Uint64 types to finish all the features but otherwise the library is working well.

[Daniil]

Great! Thank you for the feedback.

As for long/Int64 and ulong/UInt64 support, it is being under development to appear with the 1.12 release.

[kcudnik]

As for long/Int64 and ulong/UInt64 i would propose to make a compiler switch, that will specify whether use long as actual values used in js, or long that supports +/-2^31-1 values as in C#. Since javascript don't support such values natively, on bridge.net side it will require additional code to support it which may have a hudge performance impact when doing simple math operations.

[Daniil]

Hi @kcudnik,

Thank you for the feedback! Yes, there is going to be a config option to switch between JavaScript and .NET mode. The .NET mode is going to be by default.

[Vladimir]

Long values will be handled without any switch (if you use long in C# then it will be long in javascript)
Daniil meant that will be config for handling overflow (like checked C# compiler option). By default, overflow will be unchecked and clipping is performed (int.MaxValue + 1 will be clipped to int.MinValue). You can set javascript mode (without overflow checking and without clipping) or checked mode (if overflow is detected then exception will be thrown)

Long support is implemented, you can play with it if grab '64bit_support' branch (https://github.com/bridgedotnet/Brid.../64bit_support)

UPD:
The latest changes for long support are in branch Issue778_long